**** BEGIN LOGGING AT Mon Feb 11 03:00:11 2019 Feb 11 03:10:32 New news from stackoverflow: Bitbake command to locate path to installed toolchain Feb 11 08:07:42 Dear All, Feb 11 08:07:43 Can somebody explain what is the purpose of DUMMYPROVIDES ? Feb 11 08:08:02 For example in: poky/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb Feb 11 08:08:41 why the perl's packages cannot be specified in IMAGE_INSTALL_append = perl-module-locale Feb 11 08:08:51 and then those would be installed in native/nativesdk ? Feb 11 08:09:55 the DUMMYPROVIDES is also not described in the yocto manual Feb 11 08:26:37 RP: Regarding nativesdk-buildtools-perl-dummy.bb Feb 11 08:27:00 Why we don't want perl being added to buildtools (and in fact installed to nativesdk ?) Feb 11 08:27:35 I would like to have SDK with some modules installed for perl - for example perl-module-locale (locale.pm) in the SDK Feb 11 08:28:06 this module is installed fine for "normal" rootfs, so the question is why I cannot re-use it on SDK ? Feb 11 08:28:38 lukma: you either need to install perl+all the modules you need or not anything perl related at all Feb 11 08:29:05 lukma: you can certainly install perl + modules, its just not our default as the user may have other perl things they want locally Feb 11 08:31:04 RP: What I'm trying to do -> I need the locale.pm for SDK Feb 11 08:31:19 for some reason it is installed on normal rootfs Feb 11 08:31:22 but not on sdk Feb 11 08:32:44 lukma: that is is a target package, not a nativesdk one ? Feb 11 08:33:29 RP: Basically it is: perl-module-locale (as shown in package-split) Feb 11 08:35:13 but adding IMAGE_INSTALL_append = "nativesdk-perl-module-locale" Feb 11 08:35:19 shows: package nativesdk-perl-modules-5.24.4-r0.x86_64_nativesdk does not have a compatible architecture Feb 11 08:35:23 lukma: trim down target-sdk-provides-dummy ? Feb 11 08:35:51 lukma: are you after this in the target rootfs in the sdk or the nativesdk host tools Feb 11 08:37:10 RP: Could you be more specific for the last sentence? Feb 11 08:37:13 lukma: you alsmost certainly don't want nativesdk in IMAGE_INSTALL as you're mixing target and nativesdk packages Feb 11 08:37:35 lukma: an SDK has things of two architectures. Things for your target MACHINE and things for SDKMACHINE Feb 11 08:38:53 RP: So then extend: poky/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb Feb 11 08:39:09 RP: and add there nativesdk-perl-module-locale ? Feb 11 08:39:31 lukma: so you're after a perl which runs within the SDK on SDKMACHINE ? Feb 11 08:40:28 RP: The problem is: Can't locate locale.pm in @INC (you may need to install the locale module) -> and INC points to SDK installed path sysroot Feb 11 08:40:49 So I thought that I need to add it to SDK sysroot..... Feb 11 08:40:49 lukma: when running dnf in the sdk? Feb 11 08:41:28 lukma: TOOLCHAIN_HOST_TASK for that or as you say, the packagegroup Feb 11 08:42:43 RP: The dnf errors also poped up, but those were caused by the mixing /nativesdk-buildtools-perl-dummy.bb and nativesdk-perl-module-locale Feb 11 08:43:33 Greetings! I've created a custom layer and added a very simple recipe to it: it seems to be parsed, but I can't find the built executable in the end build (tried find / | grep "name"). How may I debug the building of recipes? Feb 11 08:44:04 sk_tandt_: depends a bit. can you share the recipe on a pastebin? Feb 11 08:44:17 Yup, give me a second! Feb 11 08:44:24 RP: And one more question (If I may): Is there any way to inspect in ./tmp/ the content of sysroot for SDK (as it is after installation) ? Feb 11 08:44:36 RP: I do know how to see it for "normal" build Feb 11 08:45:11 lukma: its similar to a normal build, just look for it under the image workdir Feb 11 08:46:05 RP: And what was the motivation for perl removal from SDK? The assumption that HOST will always have it installed ? Feb 11 08:46:39 lukma: for some things like buildtools, its usually not needed as the host has a complete perl install Feb 11 08:47:01 RP: OK I can find it :) Feb 11 08:47:09 http://sprunge.us/oPOWql Feb 11 08:47:38 RP: So the lesson from this is that nativesdk-* packages shall be added TO TOOLCHAIN_HOST_TASK or nativesdk-packagegroup* Feb 11 08:47:47 RP: And not mix it with IMAGE_INSTALL Feb 11 08:48:23 (but though normal package with BBCLASSEXTEND= "nativesdk" shall be installed without issues if we do not have any "optimizations") Feb 11 08:48:49 sk_tandt_: well the most obvious things to check: are you 1) actually building the recipe 2) have you added it to your image? otherwise it won't end up there. Feb 11 08:49:55 sk_tandt_: usually autotools stuff doesn't give a lot of problems. so if you are not seeing warnings like "installed-vs-shipped" or such, it probably builds and installs fine. Feb 11 08:51:20 LetoThe2nd, yep, it was indeed missing from local.conf, my vad Feb 11 08:51:25 *bad Feb 11 08:51:37 Thanks! Feb 11 08:51:45 sk_tandt_: hint: thou shall not extend your images through local.conf :) Feb 11 08:52:27 Oh? What's the best practice? Feb 11 08:52:35 RP: a penny for your thoughts: what do you think about doing some introductory tutorial streaming, like on twitch? Feb 11 08:52:49 sk_tandt_: to create a custom image recipe in your layer. Feb 11 08:53:58 Mh, not familiar with the process: any resource link plz? Feb 11 08:56:18 sk_tandt_: if you look into poky/meta/recipes-core/images, there's a couple of relatively simple images. create recipes-core/images in your layer, copy core-image-minimal-dev.bb over, rename it, and start modifying. thats how i do it. Feb 11 08:57:08 Great, thanks! Feb 11 09:00:27 sk_tandt_: i thought i had a better descriptionof the process somewhere but can't find it right now, sorry. Feb 11 10:00:02 khem: I surely don't use X11 stuff :) Feb 11 10:02:53 khem: I wonder if it's broken only on eglfs then Feb 11 10:34:36 hello, i have some issue with recipe parsing - i get the following error: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard'. I appended 'sdcard' to IMAGE_FSTYPES and bitbake -e is listing it. IMAGE_CLASSES is defined as 'image_types_fsl'. There is an image_types_fsl.bbclass in meta-fsl-bsp-release, that is inheriting image_types and defining a function IMAGE_CMD_sdcard (). The layer is added to BBLAYERS. Any idea why bitbake is co Feb 11 10:41:11 Hello again: so, the SRC_URI[hashtype] variable in a recipe binds it to a given version Feb 11 10:41:27 How do I always fetch the latest one from a remote repository? Feb 11 10:42:17 sk_tandt_: https://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#var-AUTOREV Feb 11 10:42:47 sk_tandt_: but, you have hereby been warned: this explicitly breaks reproductibility and is *NOT* recommended. Feb 11 10:43:26 Yup, it's just for dev : P Feb 11 10:43:33 Thanks for the heads-up 'tho! Feb 11 10:44:01 there's also the devupstream class which can be fun Feb 11 10:45:01 sk_tandt_: (this implcitly means that you are no more entitled to ask for support about problems cause by this, and if you do, will be billed 3.14151 * sqrt(1000) USD per question that relates to it) Feb 11 10:46:57 ahahah, loved the Pi reference, but unfortunately it didn't work Feb 11 10:50:42 well it *does* work. you're just driving it wrong :) Feb 11 10:51:16 Touché Feb 11 10:59:08 No ok, Gitlab seems to be the issue: it really doesn't like people pulling from it with git:// Feb 11 11:07:18 remember to set protocol=https, and gitlab really wants the url to end with .git Feb 11 11:07:34 ie SRC_URI = "git://gitlab.gnome.org/GNOME/gnome-desktop-testing.git;protocol=http" Feb 11 11:07:36 from oe-core Feb 11 11:13:49 RP: hey, is the python 3.7 update be in YPRR 2.7 ? Feb 11 11:14:37 Marex: it will be Feb 11 11:14:50 RP: nice Feb 11 11:14:59 not sure I understnd the RR in YPRR Feb 11 11:15:08 RP: reference release ? Feb 11 11:15:41 RP: the patch is not in master yet, is it ? Feb 11 11:16:25 Marex: its in master http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e2c3247c233876ab090c9ce3d5325a6d46ab350f Feb 11 11:16:36 oh, it's in master-next, I see Feb 11 11:16:48 Marex: no, master Feb 11 11:17:09 RP: ha, thanks Feb 11 11:19:10 RP: for the gitsm fix I can add a testcase, but it would check a very rare corner case Feb 11 11:21:02 kanavin: right, I looked at the patch and I see what you mean. I'm torn as some of these bugs are hard to stop coming back :/ Feb 11 11:22:21 RP: I do wonder though, why is there no default exception handler for this at the top level of the task? If we don't catch the exception, bitbake fails in a generic way with no indication of the exact problem, even though the exception has it Feb 11 11:23:56 kanavin: I wonder which code is squashing the decent exception Feb 11 11:24:30 kanavin: I did make a mental note to look at than when I read the patch now you mention it Feb 11 11:25:34 RP: yep, we wouldn't need the patch then Feb 11 11:48:46 RP: looks like it's this bit in lib/bb/utils.py: Feb 11 11:48:48 try: Feb 11 11:48:48 exec(code, get_context(), context) Feb 11 11:48:48 except (bb.BBHandledException, bb.parse.SkipRecipe, bb.build.FuncFailed, bb.data_smart.ExpansionError): Feb 11 11:48:48 # Error already shown so passthrough, no need for traceback Feb 11 11:49:18 the exception is bb.data_smart.ExpansionError Feb 11 11:58:47 if I remove that exception from the list, the generic handler would print a fairly ugly traceback, so I think the patch I sent is better Feb 11 11:59:58 kanavin: something still isn't quite adding up here as that block implies an exception should have been shown Feb 11 12:00:50 RP: the task-specific handler only catches the task-specific exception Feb 11 12:01:20 try: Feb 11 12:01:21 fetcher = bb.fetch2.Fetch(src_uri, d) Feb 11 12:01:21 fetcher.unpack(d.getVar('WORKDIR')) Feb 11 12:01:21 except bb.fetch2.BBFetchException as e: Feb 11 12:01:21 bb.fatal(str(e)) Feb 11 12:01:50 presumably, the exception should've been shown at recipe parsing time Feb 11 12:02:26 but SRCPV is only accessed at task execution time Feb 11 12:02:49 kanavin: no, I mean the comment # Error already shown so passthrough, no need for traceback Feb 11 12:04:53 kanavin: I think that code needs changing to print the exception and then raise bb.BBHandledException Feb 11 12:05:00 kanavin: in the expansionError case Feb 11 12:06:03 kanavin: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/bitbake/lib/bb/utils.py?h=ross/mut&id=c2852ea835a54ee967fd1e8cf3717844c338d2a1 hmm Feb 11 12:06:33 and then http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/bitbake/lib/bb/utils.py?h=ross/mut&id=8a43a6a32bafc654046250f5362509fd92dd4d10 Feb 11 12:17:48 RP: I think the comment refers to the step of parsing recipes? SRCPV isn't expanded until the unpack() task is executed, the task doesn't catch ExpansionError, and so it's never shown Feb 11 12:30:43 kanavin: the trouble is we call these exec functions in so many different contexts :( Feb 11 12:30:56 kanavin: I'd say the exception handling here is broken though Feb 11 12:31:38 RP: yeah, I'm trying to make sense of it Feb 11 12:49:42 Is there a way of making a file generated by a recipe available to other recipe in buildtime? (e.g. pubkeys) Feb 11 12:56:06 (like copying a file from a recipe's source to another recipe's source) Feb 11 12:56:13 RP: I'd say the fetch/unpack/etc tasks should be catching all exceptions, they used to do this: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=984e90f4d71d866580131c4927b0a77baf1bb9bd Feb 11 13:00:22 what fixes this on sumo? ERROR: bash-4.4.12-r0 do_package_qa: QA Issue: bash-ptest rdepends on locale-base-de-de, but it isn't a build dependency? [build-deps] Feb 11 13:01:10 can't see poky master branch fixes for this either Feb 11 13:03:31 kanavin: I'm not sure that would help :/ Feb 11 13:04:19 kanavin: The key problem we have is that at some point we need to translate an exception to something reported to the user. We need to do that once, somewhere and if we've done so, not show a traceback Feb 11 13:18:08 RP: I have another patch, where the exception information is written to a log at the point where it was previously discarded, I think that should do the trick Feb 11 13:26:40 rburton, for some reason it seems to only work with public repos Feb 11 13:27:03 sk_tandt_: oh right, yeah private repos you need to authenticate with (obviously) Feb 11 13:27:12 so http with auth or ssh Feb 11 13:27:21 git: is anonymous Feb 11 13:29:03 rburton, problem is username:password@gitlab-instance.tld isn't parsed as, say, wget would Feb 11 13:30:29 People seem to suggest to store username and pasword in .gitconfig, but where would that be located in this case? Isn't a new folder repo created on every bitbake run? Feb 11 13:34:11 ~/ Feb 11 13:46:46 we've been running morty on ubuntu 16.04 LTS. we are considering upgrading to ubuntu 18.04 LTS. will morty run correctly on 18.04? Feb 11 13:53:23 * yates looks around nervously Feb 11 14:02:32 kanavin: that sounds like the right behaviour Feb 11 14:03:17 kanavin: If its what I think it is, I'd probably just want to break it similarly to Pauls patch scenario and check that has sane output too Feb 11 14:07:50 RP: I tested it with the SRCPV problem (reverting my previous patch), and it does look sane and neat Feb 11 14:07:54 will send in a sec Feb 11 14:08:02 morty/ubuntu 18.04 LTS? Feb 11 14:13:57 RP: patch sent Feb 11 14:14:06 yates: I've had toruble running those older releases on newer Ubuntu Feb 11 14:24:33 Finally found light: git@gitlab-instance.domain.tld/group/repo.git;protocol=ssh; Feb 11 14:28:04 JPEW: thanks - good to know! Feb 11 14:48:11 rburton, I have a meson conversion list Feb 11 14:48:13 clutter-gtk Feb 11 14:48:13 gdk-pixbuf Feb 11 14:48:13 glib Feb 11 14:48:13 gstreamer1.0 Feb 11 14:48:15 gstreamer1.0-plugins.inc (bad, base, good) Feb 11 14:48:17 gstreamer1.0-rtsp-server Feb 11 14:48:19 gstreamer1.0-python Feb 11 14:48:21 gsreamer1.0-vaapi Feb 11 14:48:23 iputils Feb 11 14:48:25 libsoup Feb 11 14:48:27 libva-utils Feb 11 14:48:29 libxkbcommon Feb 11 14:48:31 lighttpd Feb 11 14:48:33 mesa Feb 11 14:48:35 orc Feb 11 14:48:37 pango Feb 11 14:48:39 xf86-video-intel Feb 11 14:48:43 xorgproto Feb 11 14:48:45 xserver-xorg Feb 11 14:48:59 glib would be a good place to start as its so low down Feb 11 14:49:12 anuj is working on mesa now Feb 11 14:50:26 cool, we should also bump the mesa version Feb 11 15:12:23 is anyone familiar with the lkms/drivers/udev rules for bluetooth? bluetooh is now non-functional my i.MX6ULL embedded image after doing some upgrades. I am not finding the bluetooth lkm loaded and don't know why Feb 11 15:13:15 e.g., on my linux desktop, lsmod reveals this: bluetooth 622592 47 btrtl,btintel,btbcm,bnep,btusb,rfcomm Feb 11 15:13:57 i cannot get a basic "hciconfig hci0 up" command to work Feb 11 15:14:08 "Can't get device info: No such device" Feb 11 15:14:58 this was working prior to the upgrades, and the upgrades did not include any mods to the kernel Feb 11 15:15:32 how is the bluetooth lkm specified to be included in the standard oe layers? Feb 11 15:16:24 i cannot find "bluetooth.*" in /lib/modules Feb 11 15:16:36 rather, i cannot find "bluetooth*" in /lib/modules Feb 11 15:18:38 check the kernel config, might well be compiled in rather than a module at all Feb 11 15:18:40 * kergoth shrugs Feb 11 15:18:58 i'd start there rather than looking for a possibly nonexistent module. if it is built as a module, make sure the module packages are installed Feb 11 15:19:23 it is a lkm on standard desktop linux (i'm using fedora 28) - wouldn't it be the same? Feb 11 15:19:45 but it certainly isn't hard to look for a config, i'll do that Feb 11 15:20:47 why would it be the same? Feb 11 15:21:06 this isn't a desktop linux distro, the requirements are completely different in many cases Feb 11 15:21:18 and the kernel configs vary, even between bsps Feb 11 15:22:21 it's also somewhat uncommon in my experience to use an initramfs to pivot to the real rootfs, which is typical on a desktop, and is required to make a lot of things modules.. Feb 11 15:22:33 but /shrug, not an expert on the yocto kernel builds Feb 11 15:28:45 Heya, anyone around this afternoon that knows setting up an autobuilder? Feb 11 15:34:07 no_such_user, currently fighting the same beast Feb 11 15:34:18 (autobuilder, with GTK on top of that) Feb 11 15:38:51 sk_tandt__: Are you using the original autobuilder or autobuilder2? It seems the public site has ditched the 1st generation one but I cant find much info about requirements for 2nd gen one and cant get it to install / run Feb 11 16:48:56 I somehow broke SDK generation again... "bitbake core-image-base -c populate_sdk" ends up in: Feb 11 16:49:19 package busybox-dev-1.29.2-r0.armv5e requires busybox = 1.29.2-r0, but none of the providers can be installed Feb 11 16:50:18 The funny thing is this does not even cause bitbake to error out... it leaves me with a half-populated SDK. Feb 11 16:50:26 on master? Feb 11 16:52:07 thud stable, but I think I have seen this on master as well some days ago Feb 11 16:52:24 I should give master a try this night Feb 11 16:53:22 bothers me it breaks on stable Feb 11 16:53:29 did it used to work? Feb 11 16:55:35 yep... I updated an old customer BSP to thud a while ago and it worked. After a sync against latest stable and rebuilding from scratch it broke. Unluckily I do not know when exactly. Feb 11 16:56:18 I have stripped out all the specific stuff and tried with this basic image, poky for qemuarm. Feb 11 16:56:53 But to be really sure I will have to run another test with a fresh checkout Feb 11 17:08:00 florian, if you find this is an issue in thud, can you open a bug please Feb 11 17:17:28 armpit: sure... but I need to reproduce it with a bare thud setup first Feb 11 17:43:56 armpit: we have reports on list of this too Feb 11 18:06:11 kergoth: found it Feb 11 18:06:18 it's a facepalm moment. Feb 11 18:07:03 actually there were two problems, but both were PEBKAC Feb 11 18:08:21 how can i found out if i'm in the middle of a "devtool modify -x" ? i.e., if there is a recipe which would be removed with "devtool reset -a"? Feb 11 18:08:31 without actually removing it... Feb 11 18:08:51 on morty Feb 11 19:07:16 i've triple-checked my recipe and associated files folder and all look good, yet the wrong file gets put into the rootfs Feb 11 19:07:18 RP: Hey Richard, what was the reasoning behind setting an empty TCLIBCAPPEND on poky? Feb 11 19:07:49 RP: Making sure only a single libc was built? Feb 11 19:07:50 is there a way to see which recipes contribute a certain file (.e.g, /etc/bluetooth/variscite-bt.conf)? Feb 11 19:08:13 i'm thinking one is stomping on the other Feb 11 19:09:16 oe-pkgdata-util find-path Feb 11 19:09:34 after a build, that is. it'll only show the recipes that have been built Feb 11 19:09:54 ok, i'll give it a shot Feb 11 19:12:28 in my CORE_IMAGE_EXTRA_INSTALL i have a few "packagegroup-xyz". are those simply recipes? Feb 11 19:14:32 kergoth: yup, there are two packages contributing that file. Feb 11 19:14:39 how do i exclude a recipe from an image? Feb 11 19:16:07 yes, packagegroups are j ust recipes Feb 11 19:16:21 find the package pulling it in and adjust the package to not depend on it anymore Feb 11 19:28:57 if i have BBFILE_PRIORITY_ebtron = "10", will a bluez5 recipe in meta-ebtron override a bluez5 recipe elsewhere? Feb 11 19:29:15 that depends on the priorities of whatever other layers provide it Feb 11 19:29:30 10 isn't magic, it depends on what the other priorities are Feb 11 19:29:36 if you mean oe-core, then yes it should Feb 11 19:30:22 i'll give it a shot. Feb 11 19:31:19 can use bitbake-layers subcommands to check Feb 11 19:37:25 in bitbake-layers, the recipe listed first is the higher priority, right? Feb 11 19:44:24 ok, dadburnit Feb 11 19:44:58 i renamed my recipe to bluez5, verified it is first in bitbake-layers, but when i bake the image i get... Feb 11 19:45:15 ERROR: Multiple versions of bluez5 are due to be built (/Storage/production-hardware-revision-A-1.0/sources/meta-ebtron/recipes-ebtron/sd-bluez5/bluez5_1.0-rc0.bb /Storage/production-hardware-revision-A-1.0/sources/poky/meta/recipes-connectivity/bluez5/bluez5_5.41.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_bluez5 to select the correct version or d Feb 11 19:45:15 on't depend on multiple versions. Feb 11 19:46:15 i thought if the priority were higher, it would just automagically select that one Feb 11 19:46:50 most likely your recipe doesn't provide everything the original does, and something depends on the bits you dont provide, so it's building both Feb 11 19:47:00 piddle Feb 11 19:50:32 kergoth: alternately, can i change my recipe name back so it doesn't conflict, and then specify that bluez5 get built and installed first? Feb 11 19:50:44 really, just installed first Feb 11 19:51:15 mine was originally named sd-bluez5 (the original is bluez5) Feb 11 19:52:15 i.e., go ahead and build both, but i want to make sure my file gets installed (stomps on) the original bluez5 file variscite-bt.conf Feb 11 19:52:35 or is that bad?? Feb 11 19:59:54 bitbake won't allow it. it'll see the file conflict long before the image is constructed and refuse it Feb 11 21:58:05 aehs29: convention for poky was to set TMPDIR to what you needed Feb 11 22:01:42 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/220 - the gpg out of memory is one thing but there is a qemu libEGL in there too :( Feb 11 22:14:28 New news from stackoverflow: How make a bitbake recipe use the output of another recipe **** BEGIN LOGGING AT Mon Feb 11 23:39:46 2019 **** BEGIN LOGGING AT Tue Feb 12 02:23:30 2019 **** ENDING LOGGING AT Tue Feb 12 02:59:59 2019