Monday, 2019-08-19

*** learningc <learningc!> has joined #yocto00:29
*** learningc <learningc!> has quit IRC00:31
*** justinsg <justinsg!uid296040@gateway/web/> has joined #yocto01:25
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC01:33
justinsgHi, does anyone know how to retrieve the version of another recipe using Bitbake? I've got some recipes on AUTOREV and so I'd like to add the PV of a recipe into the IMAGE_BUILDINFO_VARS so the revision that gets used, is recorded in the /etc/build file.01:34
justinsgI've tried using PV_pn-myrecipe but it's blank. If it helps, the IMAGE_BUILDINFO_VARS uses d.getVar() to fetch the value of each variable01:36
*** armpit <armpit!~armpit@> has joined #yocto01:37
*** chinhuat0 <chinhuat0!~chinhuat@> has joined #yocto01:37
*** chinhuat <chinhuat!~chinhuat@> has quit IRC01:39
kergothjustinsg: not possible directly. recipes can't access the metadata of other recipes by design. indirectly it can be done. but it's probably better to use the image manifest. iirc there's an option to include it in the image01:52
*** learningc <learningc!> has joined #yocto01:59
justinsgkergoth: thanks, I figured that might be the case. I think the image manifest might be the way to go, although I can only see an option to install the license manifest (COPY_LIC_MANIFEST). Supposedly the image manifest can be installed using an IMAGE_PREPROCESS_COMMAND, but I'll have to dig a bit more to figure that out. How nasty is the indirect method?02:01
*** armpit is now known as armpit_san_diego02:02
kergothyou could use pkgdata. all recipes in *this* build emit pkgdata, which are just  text files with the info used to create the binary packages. we have functions for reading the data in02:23
kergothyour task would have to depend on do_package of all the dependent recipes02:23
kergothcouldn't append to IMAGE_BUILDINFO_VARS, as one task can;'t affect the metadata of another. you could use an IMAGE_PREPROCESS_COMMAND for that method as well ast he manifest method, actually02:25
kergothstill somewhat ugly, but workable02:25
*** JPEW <JPEW!~JPEW@2605:a601:21d1:5200:620a:c230:ada8:3135> has joined #yocto02:29
justinsgkergoth: oh I see - somewhat ugly indeed. I took a look at the code that generates the image manifest, and I think oe.rootfs.image_list_installed_packages() is probably what I'm after. I can filter that a bit to create a mini manifest of the packages I specify. If I do that in a IMAGE_PREPROCESS_COMMAND task, I can probably just append /etc/build (provided I can ensure my task runs after the buildinfo02:29
kergothah, indeed, that presumably queries the package manager rather than poking around bitbake packaging internals02:30
kergoththat sounds better02:30
*** JPEW <JPEW!~JPEW@2605:a601:21d1:5200:620a:c230:ada8:3135> has quit IRC02:30
justinsgkergoth: hopefully :) thanks for your help!02:30
kergothnp, good luck with it02:31
*** comptroller <comptroller!> has quit IRC02:40
*** diego_r <diego_r!~diego@> has joined #yocto03:20
*** diego_r <diego_r!~diego@> has quit IRC03:35
*** stacktrust <stacktrust!> has joined #yocto04:12
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto06:00
*** justinsg <justinsg!uid296040@gateway/web/> has quit IRC06:05
*** AndersD <AndersD!> has joined #yocto06:12
*** goliath <goliath!> has joined #yocto06:17
*** Bunio_FH <Bunio_FH!> has quit IRC06:20
*** AndersD <AndersD!> has quit IRC06:20
*** AndersD <AndersD!> has joined #yocto06:21
*** diego_r <diego_r!~diego@> has joined #yocto06:21
*** jeanba <jeanba!~jbl@> has joined #yocto06:28
*** jeanba <jeanba!~jbl@> has left #yocto06:28
*** chinhuat09 <chinhuat09!~chinhuat@> has joined #yocto06:34
*** chinhuat0 <chinhuat0!~chinhuat@> has quit IRC06:35
*** Crofton <Crofton!~Crofton@> has joined #yocto06:35
yoctiNew news from stackoverflow: What does runqemu script? [on hold] <>06:40
*** vineela <vineela!vtummala@nat/intel/x-uskdmohmbslmxeea> has joined #yocto06:53
*** jmiehe <jmiehe!> has joined #yocto07:00
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:01
*** diego_r <diego_r!~diego@> has quit IRC07:03
*** vineela <vineela!vtummala@nat/intel/x-uskdmohmbslmxeea> has quit IRC07:03
*** TobSnyder <TobSnyder!> has joined #yocto07:10
*** tprrt <tprrt!~tprrt@> has joined #yocto07:11
*** goliath <goliath!> has quit IRC07:29
*** Bunio_FH <Bunio_FH!> has joined #yocto07:44
*** Crofton|mini <Crofton|mini!> has joined #yocto07:48
*** Crofton <Crofton!~Crofton@> has quit IRC07:50
*** kroon <kroon!~kroon@> has joined #yocto07:52
*** goliath <goliath!~goliath@> has joined #yocto08:10
*** erbo <erbo!> has joined #yocto08:32
erboIs anyone getting the "membership disabled due to excessive bounces" message from Yocto mailing list? I'm using a gmail address so I'm a bit confused to what could cause this bouncing.08:35
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:52
*** PinkSnake <PinkSnake!51ff1123@> has joined #yocto08:55
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:56
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:59
*** qt-x <qt-x!50614037@> has joined #yocto09:00
Crofton|miniIf anyone is going to Chaos Communication Camp, let me know if you want to talk about OE/YP stuff09:23
*** rburton <rburton!> has joined #yocto09:31
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:35
*** learningc <learningc!> has quit IRC09:39
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC10:01
*** learningc <learningc!~learningc@> has joined #yocto10:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:07
yoctiNew news from stackoverflow: Which yocto release tag to choose <>10:10
*** kroon <kroon!~kroon@> has quit IRC10:19
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:20
*** jij <jij!jonashg@nat/axis/x-waxqcrdlqiklykwm> has quit IRC10:22
*** cpo <cpo!~cpo@> has quit IRC10:26
*** kroon <kroon!~kroon@> has joined #yocto10:28
*** jij <jij!jonashg@nat/axis/x-eenptlbqrrycmwpm> has joined #yocto10:34
*** jij <jij!jonashg@nat/axis/x-eenptlbqrrycmwpm> has quit IRC10:41
*** cpo <cpo!> has joined #yocto10:43
*** jij <jij!jonashg@nat/axis/x-nndnauoznxufoeru> has joined #yocto10:50
*** cpo <cpo!> has quit IRC11:01
*** cpo <cpo!> has joined #yocto11:06
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:08
*** cpo <cpo!> has quit IRC11:25
*** JPEW <JPEW!~yaaic@2600:100a:b00f:bd01:9bb7:bb03:d99c:6c17> has joined #yocto11:31
*** learningc <learningc!~learningc@> has quit IRC11:39
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:39
*** berton <berton!~berton@> has joined #yocto11:44
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:44
*** berton <berton!~berton@> has quit IRC11:51
*** berton <berton!~berton@> has joined #yocto11:55
*** nabokov <nabokov!~armand@> has joined #yocto12:01
*** radsquirrel <radsquirrel!> has quit IRC12:06
*** radsquirrel <radsquirrel!> has joined #yocto12:07
*** vmeson <vmeson!> has quit IRC12:14
*** JPEW <JPEW!~yaaic@2600:100a:b00f:bd01:9bb7:bb03:d99c:6c17> has quit IRC12:14
*** learningc <learningc!~learningc@> has joined #yocto12:20
*** georgem_ is now known as georgem12:27
*** Tamis <Tamis!504e0570@> has joined #yocto12:43
TamisWhy if I put in a recipe EXCLUDE_FROM_SHLIBS=1 e.g. to a recipe that just installs Java in a path, then all libraries of Java provoke and RDEPS error?12:47
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:47
TamisDoes anyone have a clue? If I remove the EXCLUDE_FROM_SHLIBS="1" then no file-rdeps is emitted by bitbake12:48
* zeddii got booted from the yocto list due to excessive bounces. thanks gmail!12:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:00
neverpanicTamis: Chances are you have some binaries and/or libraries in your build that link against these Java libraries, and normally bitbake would auto-detect these dependencies. But since you've set EXCLUDE_FROM_SHLIBS, the data required to auto-detect where those libs come from isn't written.13:05
rburtonzeddii: i got absolutely spammed with bounce notifications this morning, halstead is trying to figure out what went wrong13:05
jwesselI wonder how much smaller the list is from auto-remove?13:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:07
*** AndersD <AndersD!> has quit IRC13:08
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:11
*** kroon <kroon!~kroon@> has quit IRC13:14
Tamisneverpanic: The recipe installs a full (binaries and libraries) pre-compiled java in a certain path. The binaries do not have any problem. Only the libraries emit this file-rdeps error. The reason I put the EXCLUDE_FROM_SHLIBS in this recipe is because those libraries should be required only from the binaries installed together in that recipe, and13:18
Tamisfrom any other recipe.13:18
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:19
Tamisneverpanic:and NOT* from any other recipe13:19
*** vmeson <vmeson!~rmacleod@> has joined #yocto13:21
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto13:22
neverpanicTamis: In our™ Java binary packaging recipe, we set PRIVATE_LIBS for this purpose.13:24
Tamisneverpanic: I was about to write that one too. So I will replace EXCLUDE_FROM_SHLIBS  with PRIVATE_LIBS13:25
Tamisneverpanic: Thanks a lot! I understaood the problem.13:26
*** Chrusel <Chrusel!c1669b04@> has joined #yocto13:27
*** yacar_ <yacar_!~yacar@> has joined #yocto13:32
*** armpit_san_diego <armpit_san_diego!~armpit@> has quit IRC13:33
*** AndersD <AndersD!> has joined #yocto13:57
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:57
*** TobSnyder <TobSnyder!> has quit IRC13:57
*** AndersD_ <AndersD_!> has joined #yocto13:58
*** AndersD <AndersD!> has quit IRC14:01
*** cpo <cpo!> has joined #yocto14:02
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:05
yoctiNew news from stackoverflow: Control a LED with BUTTON on SAMA5D27-SOM1-EK1 board <>14:11
*** yacar_ <yacar_!~yacar@> has quit IRC14:13
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:13
*** yacar_ <yacar_!~yacar@> has joined #yocto14:14
*** nabokov <nabokov!~armand@> has quit IRC14:18
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:18
*** goliath <goliath!~goliath@> has quit IRC14:25
*** qt-x <qt-x!50614037@> has quit IRC14:26
*** alimon <alimon!alimon@gateway/shell/linaro/x-aordrllpakefcuat> has joined #yocto14:30
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:31
zeddiiRP: khem: do you recall if we’ve had libc-headers specific patches to packages in the past ? I’m searching git history and I’m not finding an example14:37
RPzeddii: that doesn't really make sense14:38
zeddiiwell, it does if you can’t do a backwards compatible patch to old libc-headers :D14:39
zeddiithe 5.2 headers make y2038 changes.14:39
zeddiieverything is breaking, I have fixes.14:39
zeddiibut unless you are on libc-headers 5.2 .. the new include won’t work.14:39
zeddiiI don’t think many people vary libc-headers, so I’ll jsut make them absolute14:40
RPzeddii: the recipe in question should be detecting the presence of the header conditionally with the usual configure stuff14:41
zeddiinow that I look closer, the header is there in the older headers, so it should be safe .. just an extra include in those cases.14:41
zeddiisome packages just haven’t been patched yet, some I can just uprev.14:41
zeddiiso I can follow the upstream pattern to make them safe14:42
zeddiiseems like I sorted it out, just by typing it in :D14:42
*** sgw <sgw!~sgw@> has joined #yocto14:51
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:54
fraythe libc-headers should not have multiple versions, and don't need to match the running kernel version14:55
RPWe have one toolchain which is used to build one of two libs (roughly speaking)  and is built from one libc-headers. There shouldn't be any more variations. We don't allow people patching libc-headers conditionally or changing versions conditionally.14:57
frayyup.. libc-headers is singular.   compiler versions, libc could be different, but only one libc14:58
fray'er.. libc-headers14:58
*** goliath <goliath!> has joined #yocto15:00
*** armpit_san_diego <armpit_san_diego!> has joined #yocto15:00
zeddiiI’m past it now, works with the old and new. monday morning lack of coffee made me doubt.15:01
zeddiithis lilbc-headers update is the most painful one in a while. hopefully it’ll be ready to send out soon.15:01
zeddiiI say ignore y2038 and make my life easier! ;)15:01
fraydo they finally have some 2038 mitigation or something/15:03
zeddiisome defines, etc, are moving around. prep work to make it safe. not there yet, but packages need to adapt to the new includes.15:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:05
*** tprrt <tprrt!~tprrt@> has quit IRC15:07
yoctiNew news from stackoverflow: "inherit deploy" deploys files to just one DEPLOY_DIR_IMAGE in case of variable DEPLOY_DIR_IMAGE path <>15:11
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto15:12
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:13
zeddiifinally got through all arches on core-image-kernel-dev, now mesa is blowing up on sato.15:15
zeddiiit’ll be december before I get these tests done :D15:15
* zeddii consults master-next15:15
zeddiihmm. nothing obvious, has anyone else seen: | ERROR: Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa.15:19
*** AndersD_ <AndersD_!> has quit IRC15:20
zeddiiits in the DEPENDS of hmm.15:20
*** AndersD <AndersD!> has joined #yocto15:21
*** AndersD <AndersD!> has quit IRC15:24
kergothtotally OT, but anyone know of a command line tool which, given a time period and a command, will run the command, only if it hasn't already been run in the specified period? i.e. run this if it hasn't already been run in the past day/week/month15:30
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:30
*** Bunio_FH <Bunio_FH!> has quit IRC15:34
*** naknick <naknick!b9b8f483@> has joined #yocto15:38
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:38
*** armpit_san_diego <armpit_san_diego!> has quit IRC15:38
naknickHello! I'm trying to display video on (NXP's) IMX6 board's screen. I assume that textual OS is insufficient and I must to install GUI-based OS. Where can I find appropriate OS for that board please?15:40
zeddiinew strategy. try and figure out what is requiring mesa and kill that dependency.15:44
naknickzeddii: your answer is addressed to me?15:46
naknickbecause I'm not sure I understand15:46
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:46
zeddiinope. I’ve been having a running conversation all morning :D15:48
naknickOK :)15:48
*** yacar_ <yacar_!~yacar@> has quit IRC15:50
rburtonnaknick: depends how you want to display video.  probably best to ask NXP what they recommend though.15:52
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:54
naknickrburton: is there any GUI version which works in yocto?15:55
rburtonnaknick: i've no idea what platform youre using: yocto is a tool for building your own distro.  gstreamer is fairly standard, so is ffmpeg.15:57
naknickrburton: you say that all I need is a recipe? Is it possible to display video in Linux without GUI? =#16:02
*** sgw <sgw!~sgw@> has quit IRC16:02
rburtonnever used nxp hardware but yeah it can probably render a video to framebuffer without needing to start up a full desktop, if thats what you want16:04
naknickrburton: OK. I'll read about gstreamer. Thanks16:05
rburtonask nxp what they recommend16:06
*** cpo <cpo!> has quit IRC16:11
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:12
*** cpo <cpo!> has joined #yocto16:18
*** nabokov <nabokov!~armand@> has joined #yocto16:18
*** jmiehe <jmiehe!> has quit IRC16:18
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:19
*** vmeson <vmeson!~rmacleod@> has quit IRC16:22
*** vineela <vineela!~vtummala@> has joined #yocto16:22
khemzeddii:we explicitly ask people to use libc-headers from core, so if the end user is overriding this then they are going to fix it as well16:35
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:42
*** learningc <learningc!~learningc@> has quit IRC16:45
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:49
*** yates <yates!> has quit IRC17:11
rburtonaehs29: niiice17:17
*** goliath <goliath!> has quit IRC17:25
*** armpit_san_diego <armpit_san_diego!> has joined #yocto17:38
*** mischief <mischief!> has quit IRC17:43
*** vmeson <vmeson!~rmacleod@> has joined #yocto17:45
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:46
*** armpit_san_diego <armpit_san_diego!> has quit IRC17:57
*** goliath <goliath!> has joined #yocto18:00
*** CodePecker <CodePecker!> has joined #yocto18:17
CodePeckerHave an issue with a Nodejs Yocto recipe for a proprietary module. Using the Yocto warrior release. Looks like the npm.bbclass implementation does an 'npm install' in the do_install() step under a fake root environment. The problem I have is one of my Node.js module dependencies is hosted on a private GitLab repo. The sub-module install fails becau18:25
CodePeckerse the SSH keys cannot be accept and installed to the "/root/.ssh" directory from this fake rooted environment. Is anyone aware of a work-around?18:25
rburtonCodePecker: package your dependencies so they get fetched in do_fetch18:26
CodePeckerAre you suggesting by-passing the default behavior of npm.bbclass and effectively doing the npm install from the do_fetch (or do_compile) step? The dependencies are sitting in the node_modules directory of the NPM module I'm trying to develop a recipe for.18:29
CodePeckerThese aren't "external" dependencies. They're listed in package.json as a regular module dependency.18:30
aehs29rburton: thanks!, its POF but it works properly18:32
aehs29rburton: btw I have a "fix" for the skylake tune, idk what you guys have been up to, I wasnt suscribed to the list before, or what your plans are to merge the new tune18:36
*** alessioigor_ <alessioigor_!~alessioig@> has joined #yocto18:36
rburtonaehs29: personally, i was waiting to see if qemu gained avx over the summer18:36
*** alessioigor <alessioigor!~alessioig@> has quit IRC18:38
*** alessioigor_ is now known as alessioigor18:38
aehs29rburton: well I took a look at that and it didnt look very promising, unless you found something else that I didnt18:40
aehs29rburton: I sorta just checked what was supported on the ISA, from inside the QEMU Skylake-Client, and disabled those specifically from -march defaults18:41
aehs29rburton: gobject introspection works, and weird stuff like the v8 engine on chromium works properly as well18:41
CodePeckerrburton: Probably a noobish question, but how do you package your NPM module's (package.json) dependencies so they're fetched in do_fetch() rather than the npm.bbclass logic in the do_install() step that uses NPM to install a modules sub-module dependencies?18:43
aehs29rburton: I literally tried to disable them for specific packages, hoping they wouldnt call those opcodes, but no, looks like glibc happily tries to use avx regardless what the app thats being linked was optimized for18:43
aehs29and not just glibc, it became obvious that it wouldnt scale that way18:44
aehs29bluelightning_: do you know why the layer index isnt indexing the layers?18:46
aehs29bluelightning_: it says " The content of this layer on branch master has not yet been indexed. Indexing should take place within a few hours."18:46
aehs29bluelightning_: but it has said that for a couple of weeks now18:47
neverpanicCodePecker: Isn't that more of a npm question than a Yocto question? This isn't specific to Yocto, many distributions want this, so maybe you should check the NPM docs or how other distros (Debian?) do this.18:48
*** comptroller <comptroller!> has joined #yocto18:49
*** sgw <sgw!~sgw@> has joined #yocto18:51
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:51
CodePeckerneverpanic: Not really an NPM issue . . . more of how Yocto chose to use NPM in their do_install() procedure in npm.bbclass. Ideally, Yocto should never be pulling/fetching code from repos in a do_install() step - but it is as a by-product of calling 'npm install' there. My real issue is that do_install() is run in a fake root context. I can't upda18:54
CodePeckerte the local SSH keys as a fake "root". The install fails because it can't accept and cache the keys (as a fake root). Of course this work fine in the non-Yocto world.18:54
neverpanicCodePecker: Maybe the real issue here is that NPM doesn't seem to give you a simple way to fetch the code in do_fetch, because if there were, somebody would have implemented do_fetch in a different way in npm.bbclass?18:56
neverpanicOr maybe there is and I'm just not aware of it.18:56
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC18:56
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto19:02
CodePeckerneverpanic: It's more of a mis-match between the worlds of Yocto and NPM. NPM "install" is a combination of fetch/compile/install in one step. Not really broken into separate distinct phases like Yocto. The current Yocto approach works if all your NPM repos/registries are public and don't involve an SSH key-exchange. Can't access my key-store as a19:03
CodePeckerfake root user in do_install(). That is the crux of the problem - Yocto doesn't anticipate this scenario since it's not expecting recipes to fetch code during do_install() (as fake root).19:03
neverpanicCodePecker: That scenario also immediately breaks down if your builds don't have internet access outside of the fetch phase – which is not an uncommon setup. Plus you don't get the download cache functionality of bitbake and you can't keep a copy of your sources, so you'll have to hope that that npm module is still available for download in 6 months when you need to rebuild that old version.19:05
neverpanicSo yes, it's a mis-match between Yocto's expectations and NPM's implementation. I suggest you ask the developers of NPM to provide that functionality, since it's useful in this context.19:06
neverpanicyou might get away with moving the fetch into a phase that doesn't run in fakeroot, though…19:06
*** rcw <rcw!~rcw@> has joined #yocto19:09
CodePeckerneverpanic: I think you understand my problem. The likelihood of the NPM folks changing their already established work-flow seems unlikely. I think they'd expect Yocto to adapt instead. Your suggestions are valid and might someday bear fruit, but will probably take a coordinated effort to realize in the Yocto community. Nothing easily done in the n19:13
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC19:14
*** armpit_san_diego <armpit_san_diego!> has joined #yocto19:16
*** opennandra <opennandra!> has joined #yocto19:17
opennandrahi what is preferred way to add vendor SDK to be build in yocto (basically want to change tons of custom script for building u-boot + kernel + custom app)19:18
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:18
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto19:19
neverpanicCodePecker: the do_compile() phase doesn't usually run under fakeroot. If you can get the build and install steps separated, you can just run what you need to run there.19:25
neverpanicIf that's not possible either, again, shout at the npm folks for blatantly ignoring what distros have been doing everywhere since decades, or come up with a hack to chown/chmod all files in do_install.19:25
*** armpit_san_diego <armpit_san_diego!> has quit IRC19:26
CodePeckerneverpanic: I was mistaken. It's actually failing in do_compile() while trying to install a module dependency that should be installed from a private GitLab repository. This dependent module has a (GIT) submodule and it fails on a 'git submodule update' due to permissions issue (likely the SSH key-change). The do_install() step attempts to do an in19:31
CodePeckerstall using a local NPM cache created in the do_compile step (as best I can tell).19:31
neverpanicCodePecker: The do_compile task does not normally run under fakeroot:
neverpanicif yours does, you should check why19:36
CodePeckerneverpanic: I was confused because (devshell) now runs as fakeroot and that's where was experimenting trying to fetch this GIT submodule. The funny thing is, I have a Yocto recipe to already builds this NPM submodule independently. This other module I'm trying to create a recipe for has this submodule as a dependency. I can't figure out how to tell19:40
CodePecker is to use the one already built (even though it's listed in DEPENDS). Seems no way to inform NPM to use that instead or building it again.19:40
neverpanicit seems yarn actually provides a way to download all dependencies (, but that probably doesn't work for packages using the npm locking mechanisms, either.19:41
*** learningc <learningc!~learningc@> has joined #yocto19:41
*** learningc <learningc!~learningc@> has quit IRC19:46
CodePeckerneverpanic: Apparently NPM has some support as well:
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC20:11
bluelightning_aehs29: which layer?20:12
*** armpit_san_diego <armpit_san_diego!~armpit@> has joined #yocto20:13
bluelightning_aehs29: meta-chromebook (which was added just the other day) did get indexed...20:13
*** cpo <cpo!> has quit IRC20:13
*** cpo <cpo!> has joined #yocto20:13
*** nabokov <nabokov!~armand@> has quit IRC20:20
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC20:20
*** tgoodwin <tgoodwin!> has quit IRC20:21
*** vineela <vineela!~vtummala@> has quit IRC20:31
bluelightning_ah, meta-freertos20:31
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto20:39
bluelightning_aehs29: from what I can see here it doesn't look like there's anything preventing it from being indexed, but still it hasn't been...20:41
bluelightning_unfortunately I don't have direct access to the machine but I will talk to halstead20:41
*** rcw <rcw!~rcw@> has quit IRC20:44
*** georgem <georgem!~georgem@> has quit IRC20:47
*** georgem <georgem!~georgem@> has joined #yocto20:48
*** vmeson <vmeson!~rmacleod@> has quit IRC20:49
*** armpit_san_diego <armpit_san_diego!~armpit@> has quit IRC20:50
*** berton <berton!~berton@> has quit IRC21:15
*** opennandra <opennandra!> has quit IRC21:20
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC21:25
*** JaMa <JaMa!> has quit IRC21:28
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:40
*** dv_ <dv_!~dv@> has quit IRC21:48
*** CodePecker <CodePecker!> has quit IRC21:53
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:00
*** goliath <goliath!> has quit IRC22:00
*** dv_ <dv_!~dv@> has joined #yocto22:02
*** vmeson <vmeson!> has joined #yocto22:07
*** falstaff <falstaff!~quassel@> has quit IRC22:10
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto22:37
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC22:40
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto22:44
*** jacques is now known as jacques222:44
*** jacques2 is now known as linuxjacques22:44
*** armpit <armpit!> has joined #yocto22:49
*** mrpelotazo <mrpelotazo!> has quit IRC22:56
aehs29bluelightning_: yeah its not really a problem, I just opened it and saw that it wasnt indexed yet and its been a while, just wondering why that might be23:45
bluelightning_aehs29: well, it's definitely a problem, just not sure yet what's causing it23:46
bluelightning_there don't seem to be any related errors in the update logs23:46
aehs29bluelightning_: weird, thanks for taking a look at it thouhg23:48
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:48
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC23:52

Generated by 2.11.0 by Marius Gedminas - find it at!