Thursday, 2018-08-30

*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto00:29
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC00:31
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto00:43
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC00:45
*** stephano <stephano!~stephano@134.134.139.74> has quit IRC00:45
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto00:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC00:46
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC01:03
aehs29Im running into an issue, after installing the SDK, I am unable to compile a simple c program01:07
aehs29$ which i586-poky-linux-gcc01:07
aehs29/tmp/meta-x86/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc01:07
aehs29$i586-poky-linux-gcc a.c01:08
aehs29/tmp/meta-x86/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/8.2.0/real-ld: cannot find Scrt1.o: No such file or directory01:08
aehs29/tmp/meta-x86/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/8.2.0/real-ld: cannot find crti.o: No such file or directory01:08
aehs29/tmp/meta-x86/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/8.2.0/real-ld: cannot find crtbeginS.o: No such file or directory01:08
aehs29/tmp/meta-x86/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/8.2.0/real-ld: cannot find -lgcc01:08
aehs29I know that its supposed to get the runtime from libgcc , and the files are actually there, but I would think those paths would be set by default, either during compilation or during the relocation of the SDK01:10
aehs29and I just think its crazy how no one had noticed, which makes me think I'm doing something wrong01:10
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:12
kergothaehs29: use the variables set in the environment-setup script01:16
kergothspecifically $CC01:16
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto01:20
*** dscully <dscully!~dscully@24.249.154.174> has quit IRC01:20
khemaehs29: use $CC and $LD variables01:21
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC01:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:28
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC01:58
*** meantcoder <meantcoder!5f0a1632@gateway/web/freenode/ip.95.10.22.50> has joined #yocto01:59
*** meantcoder <meantcoder!5f0a1632@gateway/web/freenode/ip.95.10.22.50> has quit IRC01:59
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto02:03
*** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC02:29
*** chandana73 <chandana73!~ckalluri@149.199.62.254> has quit IRC02:45
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto02:54
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC03:05
*** tgraydon <tgraydon!~textual@134.134.139.73> has quit IRC03:12
*** Phreaknes <Phreaknes!~Phreaknes@71.11.113.4> has quit IRC04:23
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC04:35
*** gtristan <gtristan!~tristanva@110.11.179.72> has joined #yocto04:37
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto04:40
*** armpit <armpit!~armpit@2601:202:4180:c33:3510:374b:988:f8b2> has joined #yocto04:59
*** jacques <jacques!~jacques@nslu2-linux/jacques> has quit IRC05:20
*** dc13ff <dc13ff!uid190567@gateway/web/irccloud.com/x-pstpjtbcajytcqle> has joined #yocto05:34
aehs29kergoth: khem thanks guys let me give it a shot05:35
aehs29yeah I knew I was doing something wrong05:38
aehs29another thing that I noticed is that after passing -v to gcc05:40
aehs29the paths are wrong I think05:40
aehs29for example05:40
aehs29--bindir=/opt/poky/2.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux05:41
aehs29it contains the /opt/poky/2.5+snapshot path in there, which I know is the default where the SDK gets installed, but its not where I installed it05:41
aehs29so as far as Im concerned the relocation successfully changed it, but it changed it to the default one not the one I decided05:42
aehs29but tbh at this point I'm just doubting myself about everything05:43
khemthose paths dont matter05:45
aehs29khem: alright, I guess as long as they dont have HOST information were good, thanks05:49
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC05:53
yoctiNew news from stackoverflow: Can we add [IF] conditional statements in either .scc or .bbappend file? <https://stackoverflow.com/questions/52063827/can-we-add-if-conditional-statements-in-either-scc-or-bbappend-file>05:54
*** roxell <roxell!~roxell@unaffiliated/roxell> has quit IRC06:12
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto06:25
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC06:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:30
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:36
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC06:46
*** erbo <erbo!~erik@linode.unixshell.se> has quit IRC06:46
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:50
*** lusus <lusus!~lusus@62.91.23.180> has joined #yocto06:53
*** fl0v0 <fl0v0!~fvo@i5E863B7A.versanet.de> has joined #yocto06:57
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto07:02
*** TobSnyder <TobSnyder!~schneider@ip5f5a9a1a.dynamic.kabel-deutschland.de> has joined #yocto07:07
*** gtristan <gtristan!~tristanva@110.11.179.72> has quit IRC07:12
*** mckoan|away is now known as mckoan07:13
*** peniwize <peniwize!~peniwize@63.140.26.14> has joined #yocto07:22
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC07:30
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:33
*** CoLa|work <CoLa|work!~cordlandw@91.239.177.14> has quit IRC07:49
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto07:51
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:00
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:05
*** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto08:08
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC08:10
*** kergoth <kergoth!~kergoth@107.170.225.75> has quit IRC08:13
*** kergoth <kergoth!~kergoth@107.170.225.75> has joined #yocto08:14
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC08:26
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto08:26
*** rburton <rburton!~textual@35.106.2.81.in-addr.arpa> has quit IRC08:38
*** joaocfernandes <joaocfernandes!~Joao@88.157.234.132> has joined #yocto08:56
*** florian_kc is now known as florian09:12
*** dc13ff <dc13ff!uid190567@gateway/web/irccloud.com/x-pstpjtbcajytcqle> has quit IRC09:13
mortIs there a way to build a recipe using the host machine's libraries for the host machine's architecture?09:22
mortI ask because I now have a recipe for something that's a little non-trivial to compile, and it'd be nice to be able to use the same recipe to build the library for the host machine for development09:22
RPmort: aren't those the -native recipes?09:23
kanavinnon-trivial how?09:23
mortkanavin: well, it's WebRTC, so it involves using Google's build system, giving it a billion options to not use Google's sysroots and not use Clang's ABI and stuff, and then a step to bundle all the object files into a static library and bundle all the headers into an include/webrtc directory09:25
*** JoeR <JoeR!~JayBee@D93FFCEF.cm-21.dynamic.ziggo.nl> has joined #yocto09:25
JoeRHi all.09:25
JoeRI have a question about dependent file systems for an sdcard image.09:27
JoeRI had a class that generated a particular format of sdcard under Krogoth. I'm moving to Sumo and now this recipe fails.09:27
JoeRIt can't find the dependant ext4 fs that it needs to use for the sdcard.09:28
JoeRNow the dependencies are working correctly, and I can find the fs, just not where it used to be.09:28
JoeRIt used to get dumped in the deploy directory, but now appears to get dumped in a work sub directory of the image.09:29
JoeRI'm assuming there's a variable I *should* be using for this path, but I don't know what it is. Does anyone know?09:29
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto09:30
*** webloop <webloop!~abhijeetk@106.51.29.139> has joined #yocto09:30
mortRP: is there some documentation on how you create a -native recipe, or some existing recipes to look at? I'm having trouble finding info about it through google09:31
RPmort: most recipes just add BBCLASSEXTEND = "native". If your recipe is non-trivial, that might not work though09:32
mortI see, I'll give it a shot. Thanks09:33
RPJoeR: IMGDEPLOYDIR ?09:33
JoeRRP: Thanks. That looks right. I've been through a few variables, none hit the nail on the head. Is there a variable that reflects the name of that fs too, i.e. the one just built for that image, or should I be using the sym linked one without a date on?09:38
RPJoeR: IMAGE_NAME maybe?09:41
RPJoeR: see image.bbclass09:41
JoeRRP: Thanks.09:41
*** lusus_ <lusus_!~lusus@62.91.23.180> has joined #yocto09:41
*** lusus <lusus!~lusus@62.91.23.180> has quit IRC09:42
*** aratiu <aratiu!~adi@80.97.64.55> has quit IRC09:43
*** aratiu <aratiu!~adi@80.97.64.55> has joined #yocto09:50
*** aratiu <aratiu!~adi@80.97.64.55> has quit IRC09:53
yoctiNew news from stackoverflow: What causes BitBake worker processes to exit unexpectedly? <https://stackoverflow.com/questions/34441225/what-causes-bitbake-worker-processes-to-exit-unexpectedly>09:55
*** egavin <egavin!~egavin@24.red-217-126-80.staticip.rima-tde.net> has joined #yocto09:57
*** aratiu <aratiu!~adi@80.97.64.55> has joined #yocto10:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:10
*** mckoan is now known as mckoan|away10:13
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC10:20
*** webloop <webloop!~abhijeetk@106.51.29.139> has quit IRC10:21
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto10:27
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:28
mortPR: apparently there's no pulseaudio-native or gtk+3-native; is there a way to get bitbake to just use the system versions of that?10:28
mortRP*10:28
joaocfernandesHi everyone , I am experimenting with yocto. I have created a new layer that contains two recipes. This recipe contains two simple helloworld, the first one is called "helloworld" and is built with gcc. After I build an image run it in the target the app is present as expected.10:28
mortI totally get if there's not, because it's sort of against the whole point of yocto, but it would be a bit useful10:29
joaocfernandesthe second app is called "hellocmake" and is built with Cmake. When I do build a image I get the packages for both the recipes helloworld and hellocmake . The thing i can't understand is why the "hellocmake" is not being populated into /usr/bin/ as I expected10:31
mortjoaocfernandes: could you pastebin your two recipes and link them here?10:31
joaocfernandesyes sure, will do that10:32
joaocfernandestks10:32
joaocfernandesWorking helloworld -> https://pastebin.com/qswwnvcn10:33
mortJoeR: and the hellocmake one?10:37
mortjoaocfernandes*10:37
joaocfernandesSorry for the delay10:37
joaocfernandeshttps://pastebin.com/ZqpRy9ZS10:37
joaocfernandesI also placed some debug after the recipe10:37
bluelightningmort: ASSUME_PROVIDED += "gtk3+-native pulseaudio-native" perhaps?10:37
joaocfernandesThank you mort10:38
*** jofr <jofr!~jofr@193.182.166.3> has quit IRC10:40
bluelightningjoaocfernandes: doesn't seem to be anything wrong there, the file is packaged - so, what about the image? how are you putting hellocmake into it?10:40
mortjoaocfernandes: I think you need a do_install for cmake too, to copy the file over to ${D}${bindir}10:40
bluelightningmort: shouldn't need one - there's a default implementation in the cmake class10:40
mortah10:40
joaocfernandesI read it wouldn't be necessary on Cmake , but also tried it10:41
bluelightningwe can see from the package that the file is already being installe10:41
bluelightning*installed10:41
joaocfernandesyes10:41
joaocfernandeswill do another paste with the output image10:42
*** JoeR <JoeR!~JayBee@D93FFCEF.cm-21.dynamic.ziggo.nl> has quit IRC10:42
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto10:44
joaocfernandeshttps://pastebin.com/sb40RzkF10:44
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto10:50
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC10:51
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:52
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.204.77.163.55> has quit IRC10:53
yoctiNew news from stackoverflow: GitLab CI Yocto Build - How to use SSTATE and DL_DIR <https://stackoverflow.com/questions/52095080/gitlab-ci-yocto-build-how-to-use-sstate-and-dl-dir>10:55
*** MiskaX <MiskaX!dqzrmptv9k@rankki.sonarnerd.net> has joined #yocto10:58
bluelightningjoaocfernandes: so what do you get if you run bitbake -e your-image | grep ^IMAGE_INSTALL=10:59
joaocfernandesIMAGE_INSTALL="    packagegroup-core-boot     packagegroup-base-extended               hello"11:04
joaocfernandes:)11:04
joaocfernandesthanks for your help , bluelightning11:05
joaocfernandesI don't know why I assumed this would be installed anyway :)11:06
*** pohly <pohly!~pohly@p54BD5232.dip0.t-ipconnect.de> has joined #yocto11:17
*** MiskaX <MiskaX!dqzrmptv9k@rankki.sonarnerd.net> has quit IRC11:20
yoctiNew news from stackoverflow: Add recipes to custom meta layer from devtool workspace in Yocto Krogoth <https://stackoverflow.com/questions/52095585/add-recipes-to-custom-meta-layer-from-devtool-workspace-in-yocto-krogoth>11:25
*** MiskaX <MiskaX!luxdvijd2t@rankki.sonarnerd.net> has joined #yocto11:27
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC11:27
*** King_InuYasha <King_InuYasha!~kvirc@fedora/ngompa> has joined #yocto11:39
*** illarios <illarios!3e862e04@gateway/web/freenode/ip.62.134.46.4> has quit IRC11:52
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto12:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:10
*** roxell <roxell!~roxell@unaffiliated/roxell> has joined #yocto12:16
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC12:18
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC12:22
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto12:25
*** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC12:25
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:25
*** sveinse <sveinse!~sveinse@156.92-221-160.customer.lyse.net> has joined #yocto12:30
sveinseis there a programmically way to add an existing layer rather than editing bblayers.conf?12:31
mihaisveinse, see bitbake-layers12:33
sveinsemihai: yes, that was it. Thanks12:34
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has quit IRC12:37
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has joined #yocto12:39
*** MarcWe <MarcWe!~hmw@zimbra.welvaarts.com> has quit IRC12:42
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:43
*** zeddii <zeddii!~bruce@128.224.252.2> has joined #yocto12:46
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has quit IRC12:51
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto13:00
yoctiNew news from stackoverflow: Yocto + Autotools library + CMake application = linker error <https://stackoverflow.com/questions/52098050/yocto-autotools-library-cmake-application-linker-error>13:26
*** stephano <stephano!stephano@nat/intel/x-fgsisgvwvwtyhorj> has joined #yocto13:26
RPmort: not out the box, there are probably hacks you could do to make it use the host systems headers/libs but its not something we'd support by default13:26
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto13:27
mortI suppose the -native stuff is for tools which are needed during compilation, and those tools generally don't depend on pulseaudio or gtk, so it makes sense to not have -native versions of that13:29
RPmort: right, we try and be self contained too13:31
*** tpreston <tpreston!~thomaspre@78.40.148.184> has left #yocto13:31
mortRP: yeah, which is awesome; I've noticed it's easy to accidentally use libraries from the host system when just regularly cross compiling, and have had issues with ABI differences due to that at times13:32
*** yann <yann!~yann@81.250.171.161> has joined #yocto13:40
yannI'm defining a do_prepare_recipe_sysroot_mali-gpu_append() function in a bbappend, but it ends up replacing the contents of do_prepare_recipe_sysroot(), ie the call to  extend_recipe_sysroot() - what am I missing ?  I don't see anything in staging.bbclass doc that would explain this13:42
*** armpit <armpit!~armpit@2601:202:4180:c33:3510:374b:988:f8b2> has quit IRC13:43
*** armpit <armpit!~armpit@2601:202:4180:c33:4cc6:7ae2:a092:c40d> has joined #yocto13:44
yanndamn, _append first - could be useful to issue a warning...13:46
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:48
zeddiiRP: is there a poky-next ? or similar ? I just sent out the removals of 4.12 and 4.15 and didn't want to re-send my patch to poky to make 4.18 the default if you already had it queued somewhere.13:50
kergothyann: _mali-gpu_append is valid in certain cases. less often than _append_mali-gpu, admittedly, but both are valid and behave differently given our current file format13:52
yannhm, i see13:53
RPzeddii: poky has a master-next branch as does meta-yocto but its not a big deal for this one14:01
RPzeddii: did you see my comment about warnings yesterday? I think you may need to brace yourself to fix the kernel config warnings14:02
RPI can tell this will be 'fun' already: https://typhoon.yocto.io/#/builders/6/builds/3114:03
RP(just started a test run on the new builder and its showing warnings before its got to the main build)14:03
RParmpit: I just destroyed compatibility with the old autobuilder codebase so please don't run anything on .io atm14:07
RPI guess I shoud fix it one last time14:08
armpitRP ok14:08
armpithey, destroying  things is my job14:09
RParmpit: actually, .io is fine and ok to use, its just the old new cluster :)14:11
RPor is it the new old one14:11
RPIf its just that one, I don't think I actually care enough to fix it14:11
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC14:15
zeddiiRP: I'm taking patches from the kernel config users to cleanup warnings :D14:16
zeddiiand ok. I'll send my two patches for the 4.15 removal to poky.14:17
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto14:19
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:20
sveinseAre there any other ways to load or read the OE environment other than calling the shell-script? I'd like to avoid calling bitbake through a shell when running on our build server if I can.14:23
sveinseI'm currently calling env -i bash -c ". src/poky/oe-init-build-env; python -c 'import build; build.save_environ()'" on pre-setup of the build chain to save the environment for later direct calls to bitbake14:25
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has joined #yocto14:26
*** marka <marka!~masselst@128.224.252.2> has joined #yocto14:40
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:44
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC14:46
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC14:48
armpitRP, reminder: the sstate changes for Rocko14:55
RParmpit: merged, close it! :)14:57
armpitRP have we thought about adding hooks to git to update the bugzilla when changes got committed ?14:59
RParmpit: thought about yes, it has its issues15:01
armpitk15:03
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-eyxznmofzqgjpxva> has joined #yocto15:03
armpitRP, is it time to update https://autobuilder.yoctoproject.org/15:03
*** halstead <halstead!~halstead@drupal.org/user/301087/view> has joined #yocto15:03
armpitnew and io are listed but not typhoon15:04
RParmpit: basically, yes15:04
RPhalstead: ^^^15:04
armpithalstead, he is referring to https://autobuilder.yoctoproject.org/ updating15:05
*** ntl <ntl!~nathanl@hsvwanfw1-nat.mentorg.com> has quit IRC15:17
*** mattes_bru <mattes_bru!3ibDcRx5zT@bootes.uberspace.de> has left #yocto15:19
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto15:22
*** jacques is now known as linuxjacques15:22
yoctiNew news from stackoverflow: meta-java error while building yocto image <https://stackoverflow.com/questions/52100466/meta-java-error-while-building-yocto-image>15:26
*** varjag <varjag!~user@ti0040a400-6639.bb.online.no> has joined #yocto15:29
*** TobSnyder <TobSnyder!~schneider@ip5f5a9a1a.dynamic.kabel-deutschland.de> has quit IRC15:32
*** yann <yann!~yann@81.250.171.161> has quit IRC15:32
khemRP: recent locale overhaul is causing packaging issues with opkg works ok with rpm backend see https://bugzilla.yoctoproject.org/show_bug.cgi?id=1290515:44
yoctiBug 12905: major, Medium+, 2.6 M4, alejandro.delcastillo, NEW , core-image-lsb-sdk failed with opkg backend15:44
*** arielmr <arielmr!~quassel@187-163-217-93.static.axtel.net> has joined #yocto15:51
RPkhem: I saw, I've asked if the opkg maintainer can have a look15:51
*** dfaught <dfaught!~dfaught@12.244.19.154> has joined #yocto15:54
RPzeddii: I've added a patch to drop the 4.12 append from meta-yocto-bsp too15:54
zeddiiahaha. yes. I missed that one.15:55
RPzeddii: just had a sea of red15:56
zeddiisometing I can see on typhoon.yocto.io ?15:59
*** chandana73 <chandana73!~ckalluri@149.199.62.254> has joined #yocto16:00
zeddiiarmpit. I should have checked the OEDEM page before I booked my flights for ELCe :D16:04
* zeddii is 41 of 4016:04
RPzeddii: it was from the append, I'm rerunning with the fix16:05
zeddiiah cool. I checked and didn't see it.16:05
RPzeddii: that build is on .io16:05
RPzeddii: what may get annoying are things like https://typhoon.yocto.io/#/builders/2/builds/25 (the warnings)16:05
RPzeddii: that build is master without the 4.18 upgrade though16:06
zeddiiRP: is that warning coming out, with no actual options listed ?16:06
zeddiiI'll go see what happened, if that is the case.16:06
RPzeddii: full logs have the info, that is just capturing any lines which start "WARNING:"16:07
zeddiiahah.  I'll check the log and see if it was already caught in the patches I've been getting.16:08
RPzeddii: https://typhoon.yocto.io/#/builders/18/builds/25 has two kernel ones too (and a load of others which I don't know what we'll do about)16:09
zeddiiRP: the config patches I sent in my series this morning should clean up some of those. I can't claim all, but the CONFIG_NETFILTER_DEBUG which is showing in that log, has been removed/fixed.16:12
RPzeddii: ok. Assuming -next builds I'll be running that through this next to see how the warnings look with the updated patches16:14
* zeddii will become zeddii_home shortly16:16
*** lusus_ <lusus_!~lusus@62.91.23.180> has quit IRC16:21
*** egavin <egavin!~egavin@24.red-217-126-80.staticip.rima-tde.net> has quit IRC16:22
*** fl0v0 <fl0v0!~fvo@i5E863B7A.versanet.de> has quit IRC16:30
khemRP: another issue I am seeing is on-target g++ is not search in right directories for c++ headers16:33
khemcompile any of this examples https://www.programiz.com/cpp-programming/examples/pyramid-pattern16:34
khemit wont find c++config.h16:34
khemmy hunch is that its due to gxx-include-dir setting during configure16:34
khemregardless we should add this example to oe-selftest16:35
*** joaocfernandes <joaocfernandes!~Joao@88.157.234.132> has quit IRC16:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:38
khemRP: I think we should also do some testing with ipk backend, atleast 1 set16:39
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has quit IRC16:44
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has joined #yocto16:46
*** varjag <varjag!~user@ti0040a400-6639.bb.online.no> has quit IRC16:48
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:54
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:56
RPkhem: we do test the ipk backend https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/89616:57
RPkhem: and yes, I'd love c++ examples16:57
RPkhem: should be really easy to add, see meta/lib/oeqa/runtime/cases16:58
RPzeddii_home: https://autobuilder.yocto.io/builders/poky-tiny/builds/1229/steps/BuildImages/logs/stdio ?17:02
RPzeddii: ^^^ not sure where you are! :)17:02
RPkhem: did the perl problems in meta-oe get resolved with the cpan change?17:04
*** armpit <armpit!~armpit@2601:202:4180:c33:4cc6:7ae2:a092:c40d> has quit IRC17:06
*** armpit <armpit!~armpit@2601:202:4180:c33:4cc6:7ae2:a092:c40d> has joined #yocto17:08
khemRP: yes it did17:11
khemRP: yesterdays master-next was good.17:11
khemtoday's master-next is baking17:11
RPkhem: ok, good. I'll stop worrying about that patch then :)17:12
khemRP: yep, I have switched my staging to use master-next so you will hear from me more than you would like :)17:12
khemif the rebuild does not cause toolchain rebuilds the turnaround time of full build is couple of hrs but if glibc changes full builds are ranging from 11 to 12 hrs17:14
RPkhem: I know the problem, its doing full rebuilds atm :/17:15
RPkhem: might help if you could use our sstate17:15
khemRP: I am all for sstate reuse but data transfer could be issue17:21
khemRP: at least for home machine, my monthly quota of download quota will be done in few days :)17:21
sveinsebitbake-layers add-layer is not a particular effective tool to programmically build up one's layers... The parsing takes literally minutes, and you must take care on what order the layers are added, since parsing will fail if a layer is added in the wrong order. Perhaps I need to write my own bblayers.conf manipulator after all?17:21
kergothsveinse: richard has a patch that makes it only parse configuration, not recipes17:22
kergothand i have an unmeregd branch so it doesn't even parse configuration, just bblayers.conf an dlayer.confs17:22
RPkhem: if this is on your home system, yes!17:22
RPsveinse: http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake?id=9571101105565543aa4a811705d17fd90ad9ba0417:23
khemsveinse: we can make it better, I use it for BEC distro, we use git submodules see https://github.com/cbrake/oe-build/blob/master/envsetup.sh#L30717:23
RPsveinse: I very much want to improve the APIs17:24
kergothof everything17:24
kergoth:)17:24
RPkergoth: well, yes! :)17:24
RPI am feeling quite happy with https://typhoon.yocto.io/#/console :)17:25
RPeven if we're trending orange17:25
zeddii_homeRP:  I don’t know what happend there, but the tiny/base branches didn’t merge to the BSP ones.  I just re-pushed 4.14 and it should be fixed now17:26
kergothRP: nice.17:26
RPzeddii_home: I need patches or can just rebuild?17:27
sveinsekhem: one humble comment to git submodules handling (from our own experience with CMs): IMHO don't assume that git submodule repo == layer. Many repos, poky included, has multiple layers within the same repo. So extracting layer info from (sub)repos can be limiting functionality.17:27
zeddii_homejust rebuild. the SRCREV is right.17:27
RPzeddii_home: thanks17:27
khemRP: with those live animations can we add sound also please !!!17:28
kergothtotally and completely ot, but I'm absolutely loving my new mechanical keyboard. solid construction and feel (plate built into the top of the case), lightweight, compact, with very quiet switches but good tactile feel. HHKB-style layout takes a little adjusting, though.17:28
khemkergoth: dovrak ?17:28
khemdvorak17:29
kergothnah, still qwerty, but it has no function row, control as capslock, ` and | relocated17:29
kergoththe earlier run of https://www.massdrop.com/buy/massdrop-x-tokyo-keyboard-tokyo60-keyboard-kit?mode=guest_open17:29
RPkhem: ask upstream buildbot? :)17:29
RPkergoth: I could do with a decent keyboard!17:30
RPcouldn't survive without arrows and numpad though17:30
kergoththere are so many great mechanical keyboards out there. anything is better than rubber domes or butterfly switches :)17:30
kergoththe /r/mechanicalkeyboards wiki on reddit has a lot of great info and product recommendations for anyone wanting to get started17:31
kergothfair warning, it can be a rabbithole. i have 5 mechanical keyboards on my end table at the moment, and two $150+ keycap sets installed, and i'm a newbie :)17:32
kergothhttps://photos.app.goo.gl/BHziYlslKWNhlGVm1 looks pretty fantastic though :)17:33
khemkergoth: you should see the new mbp keyboard, it feels like banging your fingers on concrete17:34
kergothi get my new macbook pro today! first time upgrading my personal machine in *7 years*17:34
kergothbut yeah, thank god for external keyboards17:34
RPkergoth: I'm not sure I dare go down that rabbit hole :)17:37
kergothcan be one of those pricey hobbies like headphones, fountain pens, nice watches, etc, but even a cheap one is better than nothing :)17:38
sveinseI got my first 4k display (15") on my new laptop two months ago. The display is so much better than my external 2k 24" screen, so I started preferring using the laptop display. I was able to convince my boss to buy a 32" 4k external screen. And, man, programming is just so cool now.17:39
kergothawesome17:39
kergoththat's a lot of real estate17:39
kergothi've been using a 13" 2011 macbook air, not even max spec'd, as my primary machine for 7 years now. coding is doable, but mostly ssh'ing to remote build servers and single-tasking to avoid a need for more real estate17:40
sveinsekergoth: this is a screendump from my desktop: https://user-images.githubusercontent.com/13770135/44477437-f85da200-a63a-11e8-8770-0b7d8289a4f1.png17:42
sveinseSo, my conclusion is that I'd rather prefer one large 4k screen over two side by side 2k screens17:43
kergoththat's a heck of a lot of editor panes :)17:46
kergothbut agreed, not having to sort out what goes on one screen vs the other sounds nice17:46
kergothnever was a fan of multi-monitor17:46
kergothleaivng irc up on one monitor is just asking for a lack of productivity for me :)17:46
khemsveinse: vscode is good. Good choice17:46
kergothagreed, i need to play with vscode some more17:47
khemkergoth: I could edit fairly large projects, kernel, gcc ,llvm17:47
kergothaside: for anyone that didn't know, the 'bat' tool supports syntax highlighting using any sublime text package, including the bitbake one, so it gives bitbake file highlighting at a commandline, and pages. bitbake -e | bat -l BitBake works17:47
kergothkhem: impressive17:48
khemkergoth: its almost my daily driver, along side vim17:48
khemvim will always be there, unless vscode shows up on arduinos :)17:48
kergothi really *want* to use a newer graphical editor, but i'm stuck doing so many oe builds on remote fast build servers..17:48
kergothneed to code something non-oe before my coding skill rusts to nothing17:49
khemkergoth: I map the drivers over sshfs :)17:49
kergothah, nice17:49
kergothi don't think that'd work very well connecting to the build server i use that's in lahore, though. damn latency17:49
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC17:49
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto17:50
khemoh Lahore wow17:50
kergothfastest build machine we have at the moment.. the ones i use in the US are like a whopping 8 core. weak.17:50
kergothheh17:50
sveinseI was an avid emacs users before discovering vscode17:50
sveinse*user (I'm not plural)17:51
khemheh emacs17:51
kergothi wonder if tehre's a good vim plugin for vscode. i saw a new one for sublime that actually connects to a running neovim server to implement it, instead of re-implementing the vim functionality. cool stuff17:51
khemI wonder if it can make tea too now17:51
kergothwith the right IoT devices, sure17:52
kergoth:)17:52
sveinsespeaking of builds: my task now is to write the build server management for yocto. How do you guys build your yocto images? I.e. how do you manage and control the things over bitbake?17:52
khempython3 takes 1000 seconds in do_compile and its the only task running for loooong before parallelism kicks in17:52
kergothyikes17:53
khemkergoth: its running pybench.py -n 1o in qemu usermode17:54
khemforever17:54
sveinseE.g. do you use toaster or call bitbake from own scripts?17:55
khemit works lot faster for x86 but other arches it sucks17:55
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC17:55
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-eyxznmofzqgjpxva> has quit IRC17:56
khemI wonder why we run pybench17:56
khemand with -n 10 which means it will run 10 rounds17:56
khemwell here is the reason http://git.openembedded.org/openembedded-core/commit/?id=05a2a53f9cc7e75b4a3838ab9368cadf0f15ba1b18:00
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has quit IRC18:00
kergothyeah, it's quite a regression in performance. it needs to be a packageconfig at the very least18:01
kergothgood performance increase if you'rew illing to deal with teh build time, though18:01
khemI wonder how good it is to run qemuarm ( armv5te emulation ) to optimize python3 for raspberrypi3, all I can tell is it will pessimising the loads18:01
khemperformance has to be measured18:02
khemLet me open a bug18:02
khem python3-3.5.5-r1.0 do_compile - 1102s18:03
khemits still running18:03
*** zarzar <zarzar!~zarzar@184.75.233.58> has quit IRC18:03
kergothrichard indicated it was quite the benefit for nativesdk for buildtools-tarball, bitbake parse times improved with the pgo built python. should really be defaulted to disabled for target and opt-in with packageconfig for target, though18:06
khemfor native and nativesdk its fine18:16
khemI dont doubt it improves things18:16
khemdo_compile takes 25mins 2 seconds for rpi318:17
khemnot good18:17
* kergoth nods18:26
khemmay be its ok on release branches, where we dont change stuff often18:32
*** jdel <jdel!~jdel@12.1.36.234> has joined #yocto19:01
jdelhello.  I have a question regarding the linux-libc-headers package19:01
jdelthere's a big bright warning about not using a custom kernel version for libc compilation headers19:01
jdelbut doesn't that end up with the source for the uapi of the kernel being built different from that of all the userland packages being built?19:02
jdeli'm struggling with a recipe that is missing a uapi header file19:02
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC19:02
jdelthe kernel being built definitely has it, but it doesn't show up in the recipe's syroot19:03
jdelit seems like the appropriate thing to do would be to use the custom kernel for all aspects of the build (including libc)19:03
jdelso it doesn't make sense to me that an different is enforced and recommended by the build system19:03
kergothdepending on the  selected tuning, we build many packages that can be used across any number of different boards19:06
kergothunless the recipe is marked with machine arch for packge arch, it's common to any platform using that tuning19:06
kergothhardcoding it to a particular uapi for one kernel on one board would be problematic19:06
kergothnot to mention possibly not even possible withoutu changing all their tuning, due to how bitbake runs tasks19:07
jdeli'm building a custom kernel, and custom userland for a custom board19:07
kergoththat's your single use case.19:07
*** [RLA]Eske <[RLA]Eske!c0e1ba62@gateway/web/freenode/ip.192.225.186.98> has joined #yocto19:07
jdelright19:07
jdelbut that use case isn't supported?19:08
kergothif you really want to, bump the version of the linux-libc-headers recipe, problem solved19:08
jdelok19:08
kergothshouldn't have to use *your* kernel just to pick up a newer set of standard headers, just moving it to a newer kernel baselien should do the job19:08
jdelbut by default the recipe providing the kernel != the recipe providing the kernel headers?19:08
aehs29kergoth: that keyboard looks awesome, I use a mechanical keyboard as well and honestly I think its worht it19:08
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC19:08
aehs29khem: yeah the new changes to python make it incredibly slow, Id agree on the PACKAGECONFIG19:09
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto19:09
jdelthere's some custom headers in the kernel source that specific userland applications are referencing19:09
jdelit also only seems to trigger when building from sstate (if that is a clue for anything)19:09
*** varjag <varjag!~user@ti0040a400-6639.bb.online.no> has joined #yocto19:10
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto19:10
kergothif your kernel is shipping non-standard headers, then you should have a separate recipe for those which the custom userland packages depend on, rather than expcting glibc to ship them19:11
jdelokay, though linux-libc-headers makes it sound like it packages both the kernel + libc headers together19:12
jdelis that not the case?19:12
jdel(thanks for answering my questions, btw)19:12
jdeli'm trying to get a handle on how custom linux headers are supposed to be deployed19:13
jdeland included in particular recipe sysroots19:14
arielmrdoes anyone knows if there is a solid yocto overlay for nvidia tx2 ?19:19
kergothjdel: no, linux-libc-headers is the baseline sanitized headers that glibc uses, alters, and distributes wtih the rest of its userland headers. the only recipe using linux-libc-headers output dirctly is glibc19:19
jdelahh19:20
kergothi.e. its the linux headers *for* the libc19:20
jdelthat makes sense19:20
jdelso which recipes are in charge of the linux uapi headers?19:21
jdelthe provider of virtual/kernel?19:21
kergothnot certain, probably linux-libc-headrs. you can easily check with oe-pkgdata-util after doing a build19:22
kergothits find-path subcommand lets you search for paths on target wild wildcards19:22
kergoths/wild/with/19:22
*** pohly <pohly!~pohly@p54BD5232.dip0.t-ipconnect.de> has quit IRC19:26
jdelyeah, other randomly sampled kernel headers are from linux-libc-headers19:28
zeddii_homethe linux-libc-headers are uapi headers.19:33
jdelright, but my kernel has header files not included in the mainline kernel19:34
jdeland those don't make it in19:34
zeddii_homeas they shouldn't19:34
jdelso how do custom uapi headers get included by my other recipes?19:34
zeddii_homeinstall them to some other path, and have the other application look there. That’s one way.19:35
zeddii_homewhich is what we typically do.19:35
zeddii_homeor have them look at the kerne’s shared source, which is valid, since they are by definition kernel specific19:35
zeddii_homethey being the userspace application19:35
zeddii_homeor make your own libc-headers and make the whole build specific to your kernel.19:35
zeddii_homeif they are added / new headers, it isn’t such a big problem, but there’s no real way to know generically if that’s the case.19:36
jdelin the latter solutions, how does that work with sstate?19:36
zeddii_homewhich one ? your own libc-headers ?19:37
jdelit seems that when I do a full build the headers are put in to place properly, but when my kernel is "built" from sstate19:37
jdelthe headers are absent19:37
jdelin my recipe's sysroot19:37
jdelah, but that's expected I think19:38
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC19:38
*** stephano <stephano!stephano@nat/intel/x-fgsisgvwvwtyhorj> has quit IRC19:40
*** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto19:42
kergothonly what you depend on directly is guaranteed to show up in your recipe's sysroot19:46
jdelmy recipe depends on virtual/kernel, which is provided by the correct kernel with the extra header19:47
jdelthough the uapi files are not provided by the kernel build19:47
jdeli'm trying to figure out if it's just a pathing issue19:47
kergothvirtual/kernel only provides kernel headers, not sanitized kernel heaers for userland19:48
kergothand those headers only go into particular paths and will only be available if you inherit the right classes19:48
jdelie the kernel headers for eg modules19:48
kergothand shoudl only be used to build out of tree kernel moduels19:48
kergothyes19:48
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto19:48
jdelthe sstate wreng is what I'm currently fighting with. When the kernel recipe is actually built from source it apparently drops stuff in a place where my user recipe can get it19:49
jdelbut when the kernel is "built" from sstate (not sure of the nomenclature here) the files are absent19:49
jdelso my user package fails to build19:50
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:59
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC20:00
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC20:03
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto20:03
khemzeddii_home: are there in wind-river'ism in linux-libc-headers ?20:04
khemIIRC it was getting it from ko20:04
*** stephano <stephano!stephano@nat/intel/x-ityxhfttbnuedzzs> has joined #yocto20:05
zeddii_homenope.20:08
zeddii_homethey are all korg20:08
*** AbleBacon_ <AbleBacon_!~AbleBacon@unaffiliated/ablebacon> has joined #yocto20:09
*** AbleBacon <AbleBacon!~AbleBacon@unaffiliated/ablebacon> has quit IRC20:12
*** AbleBacon_ is now known as AbleBacon20:12
*** ntl <ntl!~nathanl@hsvwanfw1-nat.mentorg.com> has joined #yocto20:12
*** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto20:14
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has joined #yocto20:15
* armpit zeddii_home wound not do that.. otherwise he looses beer credits20:17
*** yann <yann!~yann@LFbn-1-515-227.w86-245.abo.wanadoo.fr> has joined #yocto20:18
* armpit time to build my layers with openssl 1.120:21
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:25
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC20:27
*** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto20:28
*** tgraydon <tgraydon!textual@nat/intel/x-vpwmmhdtihjoqzpv> has joined #yocto20:28
*** chandana73 <chandana73!~ckalluri@149.199.62.254> has quit IRC20:31
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC20:32
*** arielmr <arielmr!~quassel@187-163-217-93.static.axtel.net> has quit IRC20:33
*** chandana73 <chandana73!~ckalluri@149.199.62.254> has joined #yocto20:34
*** dfaught <dfaught!~dfaught@12.244.19.154> has quit IRC20:35
*** marka <marka!~masselst@128.224.252.2> has quit IRC20:41
*** pohly <pohly!~pohly@p54BD5232.dip0.t-ipconnect.de> has joined #yocto20:54
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC21:02
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto21:06
*** pohly <pohly!~pohly@p54BD5232.dip0.t-ipconnect.de> has quit IRC21:08
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC21:11
*** jacques <jacques!~jacques@nslu2-linux/jacques> has quit IRC21:12
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto21:13
*** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto21:14
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:23
*** peniwize <peniwize!~peniwize@63.140.26.14> has quit IRC21:25
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:27
*** dc13ff <dc13ff!uid190567@gateway/web/irccloud.com/x-uoxpjfrlqousrnbk> has joined #yocto21:48
*** peniwize <peniwize!~peniwize@63.140.26.14> has joined #yocto21:49
RPkhem: the python pgo stuff is worthwhile but we're going to need to do it differently. I want to see if building it for native than provides the same benefits for target without the long qemu usermode stuff21:52
*** arielmr <arielmr!~quassel@187-163-217-93.static.axtel.net> has joined #yocto21:54
khemRP: that would be better yes21:56
khemfor now, I think we should disable it for cross builds21:56
khem25mins is a lot of time21:57
RPkhem: llvm is even worse...21:58
*** [RLA]Eske <[RLA]Eske!c0e1ba62@gateway/web/freenode/ip.192.225.186.98> has quit IRC21:59
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:03
RPhalstead: do the two ab clusters share sstate?22:09
*** varjag <varjag!~user@ti0040a400-6639.bb.online.no> has quit IRC22:09
RP(.io and typhoon)22:09
halsteadRP, They are separate right now.22:14
halsteadRP, I can easily point them both at the same spot. Merging them would take awhile however.22:14
RPhalstead: we should share really, I assumed we were but the build speed I've just seen suggests otherwise :/22:15
RPhalstead: I'd just suggest we point everything at one of the data sets, not sure it matters which really22:15
RPprobably use the .io on?22:16
halsteadRP, Sure. I'll execute if you don't expect it will trash the typhoon build in process.22:19
khemRP: llvm is still native, its a lot of s/w to compile22:19
RPhalstead: I'll stop that and restart22:19
*** jacques <jacques!~jacques@nslu2-linux/jacques> has quit IRC22:20
halsteadRP, Okay. Making the change now.22:20
RPkhem: I know but it nearly doubles the time x86 sato images take to build22:20
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto22:20
halsteadRP, If you are stopping anyway. I'd like to reboot the workers.22:21
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto22:22
RPhalstead: ok22:23
halsteadRP, May I merge current_sources at the same time or will the clusters step on each others sources? I'm not sure if the locking changed there.22:27
RPhalstead: that should be fine too22:28
halsteadThanks.22:28
*** chandana73 <chandana73!~ckalluri@149.199.62.254> has quit IRC22:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC22:32
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto22:36
RPhalstead: just let me know when I can restart22:40
halsteadRP, I think it's safe to start it but the workers won't rejoin for a bit. I'll ping once they are all joined.22:41
RPhalstead: ok, np22:42
* armpit hmm, runqemu has fuzz logic.. it ran qemuarmi64 just fine22:44
* armpit or it can ream my mind22:45
halsteadRP, Now would be a possible time to configure destinations with a custom json config instead of with symlinks if you are interesting in supporting me through that at nearly midnight.22:51
RPhalstead: its actually really easy (I think!)22:51
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC22:51
halsteadI like easy. :)22:52
RPhalstead: take a look at http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/tree/README-WALKTHROUGHS.md the bit which says <add ~/config-local.json with contents:>22:52
RPhalstead: do that and then look at builders.py for the commented bit about config-local22:53
*** ant_home <ant_home!~ant__@host12-108-dynamic.246-95-r.retail.telecomitalia.it> has quit IRC22:59
* armpit homework for halstead23:02
* armpit quiz tomorror23:03
halstead:)23:03
halsteadRP, All paths are defined on the controller and the workers need to all match. Correct? There is no support for different paths on different workers. (Not a suggestion, just a question to make sure I understand.)23:04
RPhalstead: actually, each worker needs a config-local23:05
RPhalstead: I think different locations per worker may work but I'd not try that23:05
halsteadSo the env ABHELPER_JSON="config.json /home/pokybuild/config-local.json" needs to be set on the controller and each worker?23:07
RPhalstead: no, only the file needs to be present23:09
RPhalstead: controller takes care of the env23:09
halsteadRP, Okay I just realized there is no config.py on the workers.23:09
halsteadRP, This will be really easy once I understand the connections. Thank you for the help.23:10
RPhalstead: I had to think about it for a second as I'm used to worker==controller :)23:11
halsteadRP, Oh... I've always seen controller==master and worker==slave. With the former being considered the kinder naming.23:14
halsteadRP, So http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/tree/README-WALKTHROUGHS.md says (or set env in config.py for builders) but the commented bit in http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/tree/builders.py#n17 seems to indicate I should set it there.23:17
* armpit is a slave23:18
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:21
halsteadarmpit, To your passion for free software?23:25
armpitwife heheheh23:26
otaviokkk23:26
halsteadarmpit, Could be fun. Or not...23:27
otavioRP: I sent a bump to CMake 3.12.1. If possible, please put it on test23:27
RPhalstead: I mean my workers and controllers are usually the same machines23:28
RPhalstead: there are two ways you can set, I'd use the commented but in builders.py23:28
halsteadRP, Will do.23:29
RPotavio: its a big queue again now :/23:29
otavioRP: it is fine. Not a problem ... it is not urgent.23:33
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC23:36
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:41
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC23:46
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:51
aehs29RP: can we have a default profile for python on all machines?23:57
aehs29RP: so we dont have to run it every single time, only when we actually need to23:57
aehs29RP: and does the profile actually work even though qemu != hardware?23:58
aehs29RP: when I initially proposed it I was running it on the hw because it didnt have the same impact, but my proposal was for gcc not for python, same principle but different implementation23:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!