**** BEGIN LOGGING AT Mon Aug 19 02:59:57 2019 Aug 19 06:40:20 New news from stackoverflow: What does runqemu script? [on hold] Aug 19 08:35:45 Is 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. Aug 19 09:23:28 If anyone is going to Chaos Communication Camp, let me know if you want to talk about OE/YP stuff Aug 19 10:10:54 New news from stackoverflow: Which yocto release tag to choose Aug 19 12:47:05 Why 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? Aug 19 12:48:45 Does anyone have a clue? If I remove the EXCLUDE_FROM_SHLIBS="1" then no file-rdeps is emitted by bitbake Aug 19 12:54:03 * zeddii got booted from the yocto list due to excessive bounces. thanks gmail! Aug 19 13:05:46 Tamis: 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. Aug 19 13:05:52 zeddii: i got absolutely spammed with bounce notifications this morning, halstead is trying to figure out what went wrong Aug 19 13:06:22 I wonder how much smaller the list is from auto-remove? Aug 19 13:18:41 neverpanic: 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, and Aug 19 13:18:42 from any other recipe. Aug 19 13:19:28 neverpanic:and NOT* from any other recipe Aug 19 13:24:49 Tamis: In our™ Java binary packaging recipe, we set PRIVATE_LIBS for this purpose. Aug 19 13:25:47 neverpanic: I was about to write that one too. So I will replace EXCLUDE_FROM_SHLIBS with PRIVATE_LIBS Aug 19 13:26:32 neverpanic: Thanks a lot! I understaood the problem. Aug 19 14:11:34 New news from stackoverflow: Control a LED with BUTTON on SAMA5D27-SOM1-EK1 board Aug 19 14:37:51 RP: 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 example Aug 19 14:38:59 zeddii: that doesn't really make sense Aug 19 14:39:16 well, it does if you can’t do a backwards compatible patch to old libc-headers :D Aug 19 14:39:27 the 5.2 headers make y2038 changes. Aug 19 14:39:36 everything is breaking, I have fixes. Aug 19 14:39:51 but unless you are on libc-headers 5.2 .. the new include won’t work. Aug 19 14:40:16 I don’t think many people vary libc-headers, so I’ll jsut make them absolute Aug 19 14:41:04 zeddii: the recipe in question should be detecting the presence of the header conditionally with the usual configure stuff Aug 19 14:41:38 now that I look closer, the header is there in the older headers, so it should be safe .. just an extra include in those cases. Aug 19 14:41:48 some packages just haven’t been patched yet, some I can just uprev. Aug 19 14:42:05 so I can follow the upstream pattern to make them safe Aug 19 14:42:17 seems like I sorted it out, just by typing it in :D Aug 19 14:55:36 the libc-headers should not have multiple versions, and don't need to match the running kernel version Aug 19 14:57:28 We 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. Aug 19 14:58:19 yup.. libc-headers is singular. compiler versions, libc could be different, but only one libc Aug 19 14:58:23 'er.. libc-headers Aug 19 15:01:23 I’m past it now, works with the old and new. monday morning lack of coffee made me doubt. Aug 19 15:01:41 this lilbc-headers update is the most painful one in a while. hopefully it’ll be ready to send out soon. Aug 19 15:01:58 I say ignore y2038 and make my life easier! ;) Aug 19 15:03:00 do they finally have some 2038 mitigation or something/ Aug 19 15:04:03 some defines, etc, are moving around. prep work to make it safe. not there yet, but packages need to adapt to the new includes. Aug 19 15:11:37 ahh Aug 19 15:11:45 New news from stackoverflow: "inherit deploy" deploys files to just one DEPLOY_DIR_IMAGE in case of variable DEPLOY_DIR_IMAGE path Aug 19 15:15:23 finally got through all arches on core-image-kernel-dev, now mesa is blowing up on sato. Aug 19 15:15:31 it’ll be december before I get these tests done :D Aug 19 15:15:53 * zeddii consults master-next Aug 19 15:19:19 hmm. nothing obvious, has anyone else seen: | meson.build:768:2: ERROR: Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa. Aug 19 15:20:42 its in the DEPENDS of mesa.inc. hmm. Aug 19 15:30:12 totally 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/month Aug 19 15:40:23 Hello! 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? Aug 19 15:44:28 new strategy. try and figure out what is requiring mesa and kill that dependency. Aug 19 15:46:12 zeddii: your answer is addressed to me? Aug 19 15:46:26 because I'm not sure I understand Aug 19 15:48:24 nope. I’ve been having a running conversation all morning :D Aug 19 15:48:59 OK :) Aug 19 15:52:39 naknick: depends how you want to display video. probably best to ask NXP what they recommend though. Aug 19 15:55:58 rburton: is there any GUI version which works in yocto? Aug 19 15:57:11 naknick: i've no idea what platform youre using: yocto is a tool for building your own distro. gstreamer is fairly standard, so is ffmpeg. Aug 19 16:02:08 rburton: you say that all I need is a recipe? Is it possible to display video in Linux without GUI? =# Aug 19 16:04:42 never 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 want Aug 19 16:05:19 rburton: OK. I'll read about gstreamer. Thanks Aug 19 16:06:57 ask nxp what they recommend Aug 19 16:35:46 zeddii: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 well Aug 19 17:17:46 aehs29: https://github.com/aehs29/meta-freertos niiice Aug 19 18:25:28 Have 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 becau Aug 19 18:25:28 se 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? Aug 19 18:26:36 CodePecker: package your dependencies so they get fetched in do_fetch Aug 19 18:29:24 Are 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. Aug 19 18:30:31 These aren't "external" dependencies. They're listed in package.json as a regular module dependency. Aug 19 18:32:24 rburton: thanks!, its POF but it works properly Aug 19 18:32:26 AFAIC Aug 19 18:36:17 rburton: 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 tune Aug 19 18:36:53 aehs29: personally, i was waiting to see if qemu gained avx over the summer Aug 19 18:39:40 s/POF/POC Aug 19 18:40:07 rburton: well I took a look at that and it didnt look very promising, unless you found something else that I didnt Aug 19 18:41:20 rburton: I sorta just checked what was supported on the ISA, from inside the QEMU Skylake-Client, and disabled those specifically from -march defaults Aug 19 18:41:59 rburton: gobject introspection works, and weird stuff like the v8 engine on chromium works properly as well Aug 19 18:43:05 rburton: 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? Aug 19 18:43:53 rburton: 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 for Aug 19 18:44:45 and not just glibc, it became obvious that it wouldnt scale that way Aug 19 18:46:29 bluelightning_: do you know why the layer index isnt indexing the layers? Aug 19 18:46:55 bluelightning_: it says " The content of this layer on branch master has not yet been indexed. Indexing should take place within a few hours." Aug 19 18:47:09 bluelightning_: but it has said that for a couple of weeks now Aug 19 18:48:03 CodePecker: 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. Aug 19 18:54:46 neverpanic: 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 upda Aug 19 18:54:47 te 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. Aug 19 18:56:08 CodePecker: 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? Aug 19 18:56:19 Or maybe there is and I'm just not aware of it. Aug 19 19:03:46 neverpanic: 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 a Aug 19 19:03:46 fake 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). Aug 19 19:05:21 CodePecker: 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. Aug 19 19:06:02 So 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. Aug 19 19:06:47 you might get away with moving the fetch into a phase that doesn't run in fakeroot, though… Aug 19 19:13:03 neverpanic: 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 n Aug 19 19:13:04 ear-term. Aug 19 19:18:09 hi 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) Aug 19 19:25:06 CodePecker: 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. Aug 19 19:25:39 If 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. Aug 19 19:31:31 neverpanic: 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 in Aug 19 19:31:32 stall using a local NPM cache created in the do_compile step (as best I can tell). Aug 19 19:36:37 CodePecker: The do_compile task does not normally run under fakeroot: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/base.bbclass#n480 Aug 19 19:36:46 if yours does, you should check why Aug 19 19:40:15 neverpanic: 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 tell Aug 19 19:40:16 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. Aug 19 19:41:49 it seems yarn actually provides a way to download all dependencies (https://yarnpkg.com/en/docs/cli/pack), but that probably doesn't work for packages using the npm locking mechanisms, either. Aug 19 19:52:03 neverpanic: Apparently NPM has some support as well: https://addyosmani.com/blog/using-npm-offline/ Aug 19 20:12:44 aehs29: which layer? Aug 19 20:13:35 aehs29: meta-chromebook (which was added just the other day) did get indexed... Aug 19 20:31:28 ah, meta-freertos Aug 19 20:41:19 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... Aug 19 20:41:44 unfortunately I don't have direct access to the machine but I will talk to halstead Aug 19 23:45:51 bluelightning_: 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 be Aug 19 23:46:11 aehs29: well, it's definitely a problem, just not sure yet what's causing it Aug 19 23:46:28 there don't seem to be any related errors in the update logs Aug 19 23:48:17 bluelightning_: weird, thanks for taking a look at it thouhg Aug 19 23:48:20 though **** ENDING LOGGING AT Tue Aug 20 03:01:37 2019