**** BEGIN LOGGING AT Thu Jan 31 02:59:57 2019 Jan 31 03:20:00 New news from stackoverflow: Can't log in beaglebone as root Jan 31 04:50:17 New news from stackoverflow: Can't log in beaglebone as root [on hold] Jan 31 11:51:28 hello. can anyone explain how/or where folder with MACHINE name in ..../build/tmp/work/ is created? Because when i run "MACHINE=aarch64-sdk-generic bitbake -v -c populate_sdk core-image-iosxe" in .../tmp/work/ just is created folder with name "-iosxe-linux" Jan 31 11:55:43 easiest would be to bitbake -e core-iage-iosxe, then grep that for "-iosxe-linux". above it will show you what variables you've somehow unset and where Jan 31 11:57:43 thanks will try it. Jan 31 11:59:10 and second one question what to do if get error: "which triggered exception NameError: name 'base_path_relative' is not defined", as i understand that 'base_path_relative' is not present in my yocto for some reason. so how to understand where it is called and to which function change it? Jan 31 11:59:27 grep works Jan 31 12:00:33 if you're lucky the exception has line numbers but for anonymous blocks we don't manage to export line numbers quite right Jan 31 12:04:55 i see. Jan 31 12:06:30 i found that base_path_relative was removed from yocto, so what can i use instead of it? Jan 31 12:07:24 These base_* functions were moved into meta/lib/oe back in 2010 and wrappers Jan 31 12:07:25 left in utils.bbclass for compatibility. It's been eight years, so I think it's Jan 31 12:07:26 time to remove them. Jan 31 12:07:32 the commit tells you what to do Jan 31 12:07:57 the commit before, c97acbd034532895ce57c6717ed1b3ccc7900b0d, even ha worked examples Jan 31 12:08:50 thanks a lot. will look at it **** BEGIN LOGGING AT Thu Jan 31 12:34:12 2019 Jan 31 13:48:55 I got next error with gettext: https://pastebin.com/DdMFZYmD . As I can understand from the error, the problem is in that OE doest not find source code. But if I go to .../build/downloads, I see the archive with gettext. So I'm not sure I understand why that would be a problem for me. Jan 31 13:52:31 hello i have a quick question about ipks for a vfat boot partition Jan 31 13:53:50 when building with bitbake, ipks are created for the linux kernel and dtb files Jan 31 13:54:09 but these ipks are not installed in my wic image Jan 31 13:54:32 i do have the files in /boot partition but it seems they were just copied there Jan 31 13:54:56 they are not owned by any package when checked with opkg Jan 31 13:55:18 i was wondering if anyone had noticed this behavior in the past? Jan 31 15:00:23 rburton: looks like my package.bbclass change sends webkitgtk do_package into an infinite hang :( Jan 31 15:08:35 cedrick-cd: wic's /boot is a copy yes, because it's a separate partition Jan 31 15:25:04 Hello, I'm trying to create a isohybrid-isoimage bootable media with an extra empty partition with wic, but when I configure the /boot partition with --source isohybrid-isoimage, the extra empty partition is never created. Any idea on what can cause this? Jan 31 15:35:40 while building gcc-cross-initial_8.2.bb get strange error "NOTE: make 1 all-gcc configure-target-libgcc", try to look in log and find that in oe_runmake_call() there is "make 1 "$@"". For what is the 1 in make target? Jan 31 15:36:38 inisider: can you replicate that with no special configuration? Jan 31 15:41:03 hello, what package provides dos2unix ? Jan 31 15:41:26 dos2unix :) Jan 31 15:41:47 ERROR: Nothing RPROVIDES 'dos2unix' Jan 31 15:41:57 http://layers.openembedded.org/layerindex/recipe/87068/ Jan 31 15:42:03 you can use tr to do that Jan 31 15:42:11 rburton: currently no, but i can try to build for example for rpi3 using Thud version of yocto Jan 31 15:42:32 inisider: thud for qemux86 on poky would be interesting Jan 31 15:44:35 OT, and not helpful for the yocto bts, but https://github.com/Netflix-Skunkworks/go-jira is really nice Jan 31 16:11:33 khem: sorry for the late response, nothing obvious comes to mind from the error you sent me, where you able to figure out what's going on? Jan 31 17:24:11 adelcast1: yeah I am still diggign Jan 31 17:27:14 * edgar444 Hi! I've recently been trying out to use devshell. The manual claims that it is supposed to cd into the `${S}` _source directory_ of specified package. But I'm still in the `./build` directory. Also variable S is unset, and devshell user becomes root. I ran `bitbake rpcd -c devshell`. Do any of you use devshell, and does it relocate you? There are some variables set here, so it is doing something. Like Jan 31 17:27:14 * edgar444 `STRINGS=mips-oe-linux-strings` Jan 31 17:31:00 edgar444: I would suggest to look into devtool for doing component development, much better than all previous approaches we have taken Jan 31 17:37:16 * edgar444 khem: Yeah, it looks cool. Does it relocate you? Or do i have to specify something more. tried `cd $S`. But that's unset. I have to cd to workdir from memory or guess it. Jan 31 17:43:40 edgar444: it checks out the sources into an external directory Jan 31 17:44:04 so the sword of tmp being accidentally deleted by some bitbake operation is not hanging on your neck Jan 31 17:44:08 RP: got a minute? I'm looking for some advise regarding "filtered copies of ipk/deb for images/sdk" - https://git.openembedded.org/openembedded-core/commit/?id=c7c5f4065c102fde4e11d138fb0b6e25bffe0379 Jan 31 17:46:14 denix: I'm here for a short while yet Jan 31 17:47:00 RP: kind of non-standard issue. let's say I have an external IPK. I used to drop it into tmp/deploy/ipk and it would install into an image just fine with IMAGE_INSTALL/RDEPENDS. Jan 31 17:48:08 denix: I can see how that may be potentially problematic Jan 31 17:48:12 RP: now with the above commit for filtered feeds, it's not getting copied to oe-rootfs-repo, obviously. trying to recreate "pkgdata" for that package, but it still doesn't work Jan 31 17:48:51 denix: unpack and repack the ipk using the OE packaging Jan 31 17:48:51 denix: the pkgdata shouldn't matter, the issue is that its just not something the system knows about Jan 31 17:49:40 denix: there are probably two solutions - a) Just place the ipk into tmp/deploy/ipk/xxx using a dummy recipe to install it during a do_package_write_ipk task Jan 31 17:49:58 RP: as I understand it will only cater to packages that is generated by OE system Jan 31 17:50:03 denix: or b) add something to the rootfs package feed code so it knows about some other extra magic directory Jan 31 17:50:03 RP: right, was hoping pkgdata would be enough for the system to know... Jan 31 17:50:15 denix: pkgdata won't help Jan 31 17:50:53 denix: that code was written with determinism in mind so its now every careful that only dependencies get added... Jan 31 17:51:04 s/every/very/ Jan 31 17:52:13 RP: so, there's no easy way to get it into the system so it can be used in other regular dependencies, like it was a normal package? Jan 31 17:52:42 denix: to do that you probably need to write a dummy package installing recipe Jan 31 17:53:04 denix: or as khem says, just unpack and repack it Jan 31 17:53:46 RP: looks like your option "b" would be easiest with external feed, but it would still treat the package as external... Jan 31 17:54:00 RP: so I got OE core compiling with clang+compiler-rt+libc++ Jan 31 17:54:09 I mean most of it Jan 31 17:54:15 denix: yes, that was the plan for this kind of use case, you can add in external package feeds Jan 31 17:54:21 which does not have GNUism Jan 31 17:54:28 khem: nice :) Jan 31 17:54:37 RP: ok, thanks! Jan 31 17:54:44 RP: also also upgrade llvm to 8.0 Jan 31 17:54:48 in core Jan 31 17:55:12 khem: I saw the patches, bit depressing we have to carry more of them but inevitable I guess Jan 31 17:55:27 RP: yes for a while Jan 31 17:55:34 they are no their way upstream Jan 31 17:55:39 s/no/on Jan 31 17:55:49 much like musl Jan 31 17:56:02 some of them are already accepted Jan 31 17:56:49 as you might see they are just finding latent issues in packages Jan 31 17:59:46 khem: yes, I saw they'd been submitted which rocks! Jan 31 18:02:21 someone submitted oe patches to an upstream? *gasp* :) Jan 31 18:04:00 kergoth: :) Jan 31 18:04:08 rburton : is there any way to use ipk for /boot rather than a copy Jan 31 18:08:16 RP: I am sending glibc 2.29 patch right now Jan 31 18:08:33 RP: so keep the weekend ABs hot in polar vortex Jan 31 18:08:54 2.29 release point has been created, it will be announced tomorrow or monday Jan 31 18:09:07 i have looked through rootfs_ipk.bbclass and package.bbclass Jan 31 18:09:18 and cant quite figure out the mechanics of this Jan 31 18:18:20 RP: one issue I see with work-shared recipes is that it always setup the source tree even when none of the recipes which use that common source is rebuilt since they get reused from sstate Jan 31 18:19:07 RP: I wonder if we can notice this and avoid the unpack/patch step for the corresponding source recipe especially for gcc and kernel, Jan 31 18:19:22 I have replicated the same for clang now, which is even bigger repo Jan 31 18:19:46 so I see it spending a bit of time in doing the source setup which is not needed Jan 31 19:23:07 New news from stackoverflow: Cannot create symlink error while building with bitbake Jan 31 20:29:06 Hey, I have IMAGE_LINGUAS = "en-us es-es", build the minimal image for bbb and locale -a shows only C/POSIX locales Jan 31 20:30:01 how do I get an UTF-8 locale setup here Jan 31 20:39:35 josey: en_US.UTF-8 ? Jan 31 20:40:40 @kroon You mean using that with IMAGE_LINGUAS? Jan 31 20:40:51 hmmm, dunno what the suffix would be though. Jan 31 20:41:09 maybe check youre generated packages if you can find something matching ? Jan 31 20:48:04 any body know how LOCALE_UTF8_ONLY and LOCALE_UTF8_IS_DEFAULT work Jan 31 20:49:22 utf8_is_deafult makes en_US utf8, rather than the normal behavior of en_US as non-utf8 and en_US.UTF-8 as utf8 Jan 31 20:49:29 deviates from most linux distros Jan 31 20:49:34 iirc anyway Jan 31 20:52:15 so far seems I missing something else as, there isn't neither en_US en_US.UTF-8 in my image Jan 31 20:52:29 just C/POSIX Jan 31 20:53:25 New news from stackoverflow: How to install graphics drivers in Yocto output image Jan 31 20:55:38 josey: that's entirely controlled by IMAGE_LINGUAS.. Jan 31 20:55:44 assuming those locales were generated anyway Jan 31 20:55:50 check GLIBC_GENERATE_LOCALES Jan 31 20:57:53 maybe I need to add localedef? Jan 31 20:58:00 seems that was missing in my image Jan 31 21:04:02 josey: didn't we go through this yesterday? set LOCALE_UTF8_IS_DEFAULT="0" Jan 31 21:04:11 en_US *is* utf8 in oe by default Jan 31 21:04:52 rburton: Yes, but I din't get the image to work, still have only C/POSIX locales after rebuild Jan 31 21:05:14 you probab;y need to change the install list too Jan 31 21:06:52 rburton: what install list ? Jan 31 21:22:22 Hey - i notice mongo is disabled for arm currently. Is there a working layer anywhere for mongodb on the pi? Jan 31 21:22:31 disabled in meta-oe i mean **** ENDING LOGGING AT Fri Feb 01 02:59:56 2019