**** BEGIN LOGGING AT Tue May 05 02:59:57 2020 May 05 05:53:07 OutBackDingo: or in other words, "it depends" May 05 06:34:06 hum, devtool doesn't seem to use a memory resident bitbake instance, right? May 05 06:39:59 khem: anything blocking you from branching out (dunfell) for meta-clang ? May 05 07:22:11 henriknj: nothing, but there is no breaking change in master yet so keep master working for both dunfell as well as master so we can get some more issues May 05 07:22:14 if any May 05 07:22:36 khem: alright May 05 08:17:32 paulg: we can do it all in house... im just curious about any "caveats" ... or things to consider. May 05 08:18:37 im tryiong to consider use the existing wheels, or reinvent the wheerl kinda thing May 05 08:19:48 OutBackDingo: it really depends on if your usecase mandates some features that yocto would provide. May 05 08:20:47 unless you can provide a properly described usecase, it certainly is "can be done, no idea if it fits your needs." May 05 08:28:21 know that you are building your own server from source, so security patching will be on you. there wont be convenience of apt update or dnf update fom somewhere unless you set it yourself May 05 08:29:22 you might not get any "server tunings" etc. that these distros might have done. May 05 08:29:30 ... which can be both up-or downside again. think of ci-building the os, and cyclically rebooting it from the cd pipeline. May 05 08:31:38 to me, its really a question like "can i use a car to transport an item from here to there". without describing the item, the distance, and all other constraints. so "it depends" May 05 08:31:45 servers can be large and if its a baseline which one expects to adapt to different types of servers then its fair amount of work. essentually perhaps to setup feeds or some such May 05 08:32:07 to fit in these needs. and then you are basically doing a binary distro May 05 08:32:31 all guesswork May 05 08:33:26 don't get me wrong, averything you say is technically correct, yet everything is also based on personal experience and what we assume a "server farm" to be like. May 05 08:37:37 khem, hi May 05 08:40:00 binutils-cross-armm fails to build with ../../gold/expression.cc May 05 08:40:00 | g++: internal compiler error May 05 08:40:48 Makefile:1137: recipe for target 'powerpc.o' failed May 05 08:40:48 yeah gold is flaky May 05 08:41:01 dont use it if you dont need to May 05 08:41:04 it's master-next here May 05 08:51:13 I can't easily find the regression, must be in these last two weeks May 05 09:05:29 Hi guys. I was wondering, should devtool use python from the host or native python from sysroot? May 05 09:06:45 UVV: host one, pretty. sure. reasoning: you can run devtool without even having built something at all. just like bitbake itself. May 05 09:19:46 LetoThe2nd Alright, then it seems I faced an issue where environment variables got messed up somehow May 05 09:20:36 File: '/usr/lib/python3.8/sysconfig.py', lineno: 421, function: _init_posix 0417:def _init_posix(vars): May 05 09:20:37 0418: """Initialize the module as appropriate for POSIX systems.""" 0419: # _sysconfigdata is generated at build time, see _generate_posix_vars() May 05 09:20:37 0420: name = _get_sysconfigdata_name() *** 0421: _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0) May 05 09:20:38 0422: build_time_vars = _temp.build_time_vars 0423: vars.update(build_time_vars) May 05 09:20:38 0424: 0425:def _init_non_posix(vars): May 05 09:20:39 Exception: ModuleNotFoundError: No module named '_sysconfigdata' May 05 09:20:43 That's the stacktrace May 05 09:21:06 (somehow the formatting is messed up) May 05 09:21:16 Exception: ModuleNotFoundError: No module named '_sysconfigdata' May 05 09:21:26 It seems this is the source of error May 05 09:22:18 I traced that value and see that this got assigned in meta/classes/python3native.bbclass as export _PYTHON_SYSCONFIGDATA_NAME="_sysconfigdata" May 05 09:23:57 The failing function is _get_sysconfigdata_name() from /usr/lib/python3.8/sysconfig.py May 05 09:24:36 when I run it manually I get a correct value: _sysconfigdata__x86_64-linux-gnu May 05 09:25:08 Just one step back, the whole thing happens when I run 'devtool modify myrecipe-native" May 05 09:25:21 I'm on zeus branch, btw May 05 09:25:28 any idea what could have gone wrong here? May 05 09:25:36 khem, the default distro does not use goldm I see binutils-cross correctly configured May 05 09:25:44 --enable-gold --enable-ld=default --enable-threads May 05 09:29:19 UVV: what host distro are you on? has it ever worked? and so on, and so on. May 05 09:33:41 Hi Everyone May 05 09:34:50 LetoThe2nd It's Ubuntu 20.04 at the moment, I tried about a month ago on Ubuntu 19.04 was the same behavior May 05 09:35:24 UVV: a run of the mill zeus? and a real, untinkered ubuntu 20.04 (specifically, not a WSL one?) May 05 09:40:06 Not sure what's a WSL ubuntu, TBH. May 05 09:40:29 lsb_release -a shows Description: Ubuntu 20.04 LTS May 05 09:41:08 On the zeus, I do have a bunch of my layers used of course May 05 09:41:08 UVV: WSL is the windows subsystem for linux, e.g. running linux as a windows application (roughly) May 05 09:41:26 Ah, no, of course not May 05 09:42:02 UVV: well, people show up trying to do that, hence the question. May 05 09:42:21 UVV: what happens if you remove all layers besides poky itself? May 05 09:42:40 and try with another 'standard' recipe you mean? May 05 09:42:45 UVV: e.g. trying to build core-image-minimal for qemuarm, or something similar? May 05 09:42:57 I am using DISTRO_VERSION = "2.4.3" and I see that package and packages-split directory do not get created sometimes for few targets/recipes and those targets have breakpad integrated and inherit breakpad, breakpad packages symbols in /usr/sym/ which I find in package and packages-split directories could anyone tell me why package/packages-split May 05 09:42:58 directory is not created or how to package/fetch breakpad symbols of the target May 05 09:43:21 LetoThe2nd well the images and recipes build fine. That's only a devtool that fails for me. May 05 09:43:39 UVV: ah ok, now i get the point. hm. May 05 09:44:30 LetoThe2nd: on the other hand, my recipe inherits python3native class.. I wonder if that has something to do with it May 05 09:45:09 UVV: your recipe shall inherit that class if you specifically need python3 during its build time. May 05 09:46:10 LetoThe2nd yes, it does. I wonder if that has something to do with 'devtool' failing May 05 09:46:54 UVV: does devtool only fail for that specific recipe? May 05 09:48:47 LetoThe2nd that's what I'm gonna try now.. May 05 09:49:08 @ashv270 isn't package split can be redefined by a recipe? May 05 09:55:46 Hi, in my Makefile called from a recipe I need to call objcopy from binutils to generate an ELF file suitable for linking with my application. Using $(OBJCOPY) already calls the correct objcopy variant. May 05 09:55:47 I also need to pass the correct options to "-B" and "-O". e.g. for amd64 these would be "i386" (yes, really) and "elf64-x86-64", respectively. For AArch64-LE, they would be "arm" and "elf64-littleaarch64". Are there predefined variables for those? May 05 09:56:09 LetoThe2nd devtool worked for another (arbitrary) recipe. Next steps to try: native recipe (1), and finally another native recipe that uses python (2) May 05 09:57:47 LetoThe2nd: native worked too.. final test :) May 05 10:00:11 LetoThe2nd yeah... I think I've got a reproducible test case, which hopefully you could try too :) May 05 10:00:13 devtool modify rpm-native May 05 10:01:02 UVV: hehe, sorry, but i don't have time to set up a 20.04 and try to reproduce. if you are certain that it also applies to a raw, untikered poky, then please submit it to the bugtracker :) May 05 10:02:11 LetoThe2nd: NP, although I'm pretty sure it would fail on 19.04 too. Which distro are you on? May 05 10:02:33 Erlkoenig: no May 05 10:02:56 LetoThe2nd: I will look up for a bugtracker link.. I've also just thought that a workaround might be not to use native with devtool. May 05 10:02:57 Erlkoenig: presumably you're trying to link a piece of non-executable code into the elf as a new segment? May 05 10:03:28 LetoThe2nd I am not sure whether package split can be redefined but both package and package-split get created sometimes on building full image while sometimes they do not get created and when package/package-split not crated I can not find the breakpad symbols in WORKDIR for that target/recipe May 05 10:04:37 LetoThe2nd ha, workaround didnt' work. 'devtool modify rpm' failed too May 05 10:05:11 ashv270: package splitting can be redefined AFAIK, but my guess is that you are just doing something that is not reproductible in the recipes, e.g. some magic outside of the scope that bitbake can see. May 05 10:06:50 ashv270: builds from sstate won't create a package-split or package directory in the workdir May 05 10:07:08 *never* expect anything in tmp/work to exist outside the recipe you are currently building May 05 10:07:10 ashv270: chiming in without too much context, but if you want to operate on files from packages and package-split, you actually want to modify them from image directory (${D}) in or after do_install task. May 05 10:10:14 khem, doh, it did compile on next run May 05 10:24:31 rburton: Exactly, using the common binary-to-elf trick to load some binary blob along with the code May 05 10:33:06 Erlkoenig: http://www.burtonini.com/blog/2007/07/13/embedding-binary-blobs-with-gcc/ works without needing to know arch types May 05 10:33:16 RP: have you forgotten to replace "this layer" in your commit log of your last patchseries? it's rather confusing :/ May 05 10:34:09 rburton: Sure?! I think that will trigger a linker error because the architecture of the generated .o file differs from the target executable file May 05 10:34:38 qschulz: there are a few too many words in there... May 05 10:34:57 Ah wait it works because you invoke the right "ld"... May 05 10:34:59 RP: its a compressed message :) May 05 10:35:19 Erlkoenig: right. haven't tested it in a cross build but by using higher level tools is should work May 05 10:35:57 qschulz: I pushed a better version to master-next May 05 10:45:15 RP: I understand now why I was so confused... There was no mention to which layer those patches should be applied :) May 05 10:45:24 I'm surprised it's the same ML for meta-gplv2 May 05 10:46:28 or maybe I'm mixing up everything again oe-core, poky, yocto, etc. May 05 10:48:44 qschulz: yes, sorry, I missed the prefix didn't I! :) May 05 10:49:13 any idea for my opkg related post install script question from a C program? May 05 11:23:38 zeddii: narrowed to between 5.4.34 and 5.4.38, i.e. your last patch May 05 11:25:01 lpapp: PATH differences? May 05 11:26:55 Hello, Is it possible to change systemd service to not be enabled by default but from image not bbappend? May 05 11:27:22 In particular I want to disable systemd-networkd and start it on demant from application May 05 11:27:54 tolszak: no, not from the image recipe. the recipe that installs and emables the service has no idea what happens in another recipe. May 05 11:27:57 rburton: It worked, thanks! May 05 11:28:02 I tried to set SYSTEMD_AUTO_ENABLE-systemd-networkd = "disable" May 05 11:28:14 tolszak: https://twitter.com/TheYoctoJester/status/1217166071519744000 May 05 11:28:43 Ahh image is recipe May 05 11:28:55 so it can be only machine or local right? May 05 11:29:03 tolszak: or append. May 05 11:29:10 tolszak: or distro config. May 05 11:29:29 aaaaa distro! good good. LetoThe2nd: Thanks! May 05 11:29:44 (with the append or distro being the two btter choices than machine or local) May 05 11:34:43 I am trying to run toaster. I do: May 05 11:34:53 source oe-init-build-envsource toaster start May 05 11:35:40 source toaster start, but I get layers/poky/bitbake/bin/toaster:264: = not found May 05 11:35:52 I am on zeus, anybody ever seen this? May 05 11:36:15 that is two source statements, right May 05 11:36:28 no May 05 11:36:34 I messed up, never used irc May 05 11:36:52 source toaster start gives me "layers/poky/bitbake/bin/toaster:264: = not found" May 05 11:38:45 maybe look at line 264 and see what variable is being expanded to nothing May 05 11:49:36 my mistake, I was on zsh. ofc it didn't work. switching to bash fixed it May 05 12:33:27 RP: I have used getenv for PATH, but could not notice much difference May 05 12:34:03 lpapp: I wondered if it was something like /sbin or /usr/sbin being missing May 05 12:35:07 yeah, I had the same thought May 05 12:47:04 RP: I have just printed this before my execvp, is that the place in the flow where you would also check? log_debug("TEST INSTALL, GETENV(PATH-SUPATH): %s-%s", getenv("PATH"), getenv("SUPATH")); May 05 12:47:46 I am using `devtool modify linux-imx` just to reword the commit message of one of the patches I have applied to my kernel. But `devtool update-recipe linux-imx --append ` does not detect this. I then tried with --force-patch-refresh, but I end up with a newly created directory called `linux-imx:` (yes, colon at the end) with a bizarre layout inside, and the new patches buried in there. Can someone help me achieve what I want - to just auto-update May 05 12:47:46 the one .patch file? May 05 12:50:07 I have a recipe on warrior which ended up with a nasty " texinfo-nativegrub-efi-native " in its DEPENDS - where I'm surprised is that the recipe proceeded only to fail because of the missing deps (as far as do_package), but I never got a complaint about the non-existent dependency - does that talk to anyone ? May 05 13:01:08 in fact, I can add this to any recipe, and bitbake does not complain: DEPENDS += "texinfo-nativejunk-that-does-not-exist" May 05 13:01:53 could not find any other prefix than "texinfo-native" with this effect, but this one is pretty efficient :) May 05 13:14:00 RP: I just went and sent all of the remaining patches, quite many of them are simple corrections :) May 05 13:16:25 kanavin_home: thanks, I've added it and triggered a build May 05 13:16:57 Going to have to make a decision about what to do with multilib :/ May 05 13:29:48 RP: ditch it already! "one machine for 64b, one machine for 32b, then you use multiconfig to bring the things together." May 05 13:31:58 qschulz: I wish :) May 05 13:32:15 yann: there are some assumptions with -native being a suffix I think. Maybe you could try with -nativesdkjunk-that-does-not-exist as well. I know nothing about the internals though... Also, look the actual DEPENDS that is pulled (-native I guess?) May 05 13:35:21 at least grub-efi-nativejunk-that-does-not-exist was signaled as non-existent - as for "nativesdk" it benefits from "native" being a prefix, so it gets unreported as expected May 05 13:37:56 so it seems that `devtool update-recipe ... --append ...` is not able to parse multiple paths in FILESEXTRAPATHS_prepend May 05 13:38:15 yann: duh for nativesdk /me facepalms May 05 13:39:36 i openned a ticket in bugzilla - there's nothing urgent in this once the missing space has been inserted in the recipe :) May 05 13:42:13 RP: this is the path, /sbin:/sbin:/usr/sbin:/bin:/usr/bin May 05 13:42:16 from within the C program May 05 13:42:35 but there is some setuid binary involved, I guess that cannot change things? May 05 14:15:20 Hi guys, I have read that fitImage does not work well with 64bit RPI kernels. my question is, is this a configuration issue or u-boot for some reason does not support it? May 05 14:17:35 as a second question, could you point me to any documentation where I can see how to write files to a different partition other than boot and rootfs? May 05 14:27:58 Hmm, vcs_tag() is problematic in meson.... For tarballs (e.g. weston, libinput) it picks up the revision of the parent git repo May 05 14:28:14 (e.g. oe-core, poky, whatever) May 05 14:28:41 ouch May 05 14:28:59 doesn't git have a 'don't recurse up' option? May 05 14:32:30 it does, but meson implements it's own walk up the file tree looking for a .git directory: https://github.com/mesonbuild/meson/blob/master/mesonbuild/mesonlib.py#L545 May 05 14:33:42 JPEW: ah May 05 14:34:38 Well more correctly, I don't actually know if git has an option for that, but it doesn't matter because of what meson is doing May 05 14:52:42 YPTM - armin is on May 05 14:52:45 JPEW: We've seen that before with other projects May 05 14:53:24 JPEW: git does have an option for it FWIW, we need to "fix" meson as it breaks reproducibility badly May 05 14:56:02 armpit: way early! :) May 05 14:58:01 I was late by 2 minutes May 05 14:58:23 YPTM - Jan-Simon is on May 05 14:58:47 YPTM - Joshua Watt here May 05 15:00:03 YPTM Scott Murray is on May 05 15:02:14 HI, Could someone give me any hint how to make bbappend which will be used for differnet HW ? May 05 15:03:09 In bbappend I specified COMAPTIBLE_MACHINE but with this setting bitbake gives error that there is nothing to provides ... May 05 15:04:05 which looks like it was populated for complete package May 05 15:04:30 rokm: bbappend is appended to the recipe, so you effectively just redefine COMPATIBLE_MACHINE multiple times May 05 15:05:42 YPTM Alejandro joined May 05 15:06:03 YPTM Saul hopped on for a change! May 05 15:06:18 rokm: what you could do (not knowing what are your issues/requirements) is to make the content of those bbappends machine specific by using VAR_machine1 or VAR_machine2 (if redefining, otherwise you need VAR_append_machine1). same is possible for tasks do_task_machine for redefining, do_task_append_machine for appending for a given machine May 05 15:06:23 sgw: oh wow May 05 15:07:24 qschulz: bbappend just adds some specific files to rootfs So basically there is one install in do_install_append May 05 15:08:23 and this one file I want to install only for eg. X but the rest which is in bb file for all machines (common) May 05 15:09:08 rokm: depends exactly what you're trying to do. You could technically create another package in your recipe and put the files there. Then in your image have IMAGE_INSTALL_append_machine = "" or if it's really needed by the machine can be put into the machinec onf file with MACHINE_EXTRA_RDEPENDS for example May 05 15:09:42 the benefit from that is your recipe is not machine specific, only your image recipe May 05 15:09:44 sakoman: please consider adding http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c920ec0f8a215b59580bedf10909cfb31141190e to your dunfell-next May 05 15:11:11 sakoman: fyi: https://pkgs.org/search/?q=gcc May 05 15:11:29 thanks! May 05 15:11:33 it would be nice to be able to query pkg versions but I haven't figure out how to do that. May 05 15:11:51 qschulz: sounds good, thanks May 05 15:12:27 moto-timo, sakoman The Fedora32 worker is partially provisioned. It's showing gcc-10.0.1-0.11.fc32.x86_64. May 05 15:17:34 sakoman: you can just query: https://pkgs.org/search/?q=gcc-10 and gcc10 but that's clearly sub-optimal May 05 15:18:42 dl9pf: that patch will go in next week May 05 15:19:25 sakoman: thanks a lot May 05 15:36:35 sgw: You left before I could say hi! May 05 15:36:51 Hi, sorry had an 8:30! May 05 15:37:25 sgw: np, was just going to say hi and noticed you'd gone! May 05 15:38:09 Nice to hear folks voices! Also I like the idea of an LTS, I know it's been a long time coming! May 05 15:49:11 what's the Siemens tool? May 05 15:51:49 tlwoerner: kas I think? (without any context, wild guess) May 05 15:52:11 qschulz: the context is from the yptm meeting (ongoing) May 05 15:52:15 thanks May 05 15:55:05 paulbarker: https://github.com/garmin/pyrex May 05 15:55:40 JPEW: Thanks! May 05 15:57:18 so that whole last discussion was about tools etc to be able to run OE/Yocto builds in CIs? or just automated ways to do builds in containers? May 05 15:57:54 zeddii: I've merged the other kernel patches, I'll wait on the final one until we get to the bottom of the reproducibility issue May 05 15:57:54 tlwoerner: A bit of both May 05 15:58:27 paulbarker: thanks. i couldn't tell if it was wandering into different topics or not May 05 15:58:36 * tlwoerner looks forward to the talk! May 05 15:59:39 My setup is still WIP but it's coming together well. I think CROPS is the right container setup for me, when I'm doing CI builds the git clone and everything else is actually running in the container May 05 16:01:18 RP: Thoughts on setting `export GIT_CEILING_DIRECTORIES = "${WORKDIR}"` in bitbake.conf? I can't think of a reason why we would want git it a task walking up past WORKDIR May 05 16:08:17 JPEW: need to exclude from hashes but probably not a bad idea May 05 16:10:47 JPEW: looks very sensible to me May 05 16:25:37 Ok. It fixes the version detection in meson, so I'll make the change May 05 16:29:38 <[Sno]> otavio: maybe we should move discussion wrt. master-next, ci etc. from github to here :) May 05 16:30:00 <[Sno]> otavio: or do like raku folks and open an issue for that May 05 18:19:31 hi folks. i need to do some post-processing on files after do_populate_sysroot. i've tried hooking sysroot_preprocess_funcs but that doesn't really seem to be doing the trick. May 05 19:13:25 [Sno]: well, it depends May 05 19:14:07 we can do a short discussion but then we'd gain more wider discussion moving it to github May 05 19:15:16 I did a small test using githb actions and circle ci and in both cases, faced time out May 05 19:34:53 Does yocto support builds on an external (exFAT) USB hard disk? May 05 19:38:01 mmort: external, yes. exfat, probably not May 05 19:38:53 Yeah, I'm getting i/o errors May 05 19:39:04 <[Sno]> otavio: I'm fine doing it on gh :) May 05 19:40:18 <[Sno]> otavio: the only benefit discussing here is when people are here at the same time, that one can interact bit better and avoid some wrong directional thoughts have time to grow :) May 05 20:05:07 Does anyone know how to make the assembled (gas secifically) include the FILE symbol? May 05 20:05:19 s/assembled/assembler/ May 05 20:05:58 perf isn't reproducible because one assembly file doesn't have the FILE directive and the linker makes one up with the absolute path May 05 20:23:33 RP: it seems that updating icu causes hashequiv to take more shortcuts than it should May 05 20:23:45 in particular, vte is not rebuilt, and it should be May 05 20:23:48 kanavin_home: I was just looking at your email May 05 20:23:55 and I just confirmed this locally May 05 20:24:02 kanavin_home: My first thought was to run away screaming May 05 20:24:13 kanavin_home: I suspect something that should have an icu depends doesn't May 05 20:24:38 * RP wakes the build machine May 05 20:25:06 RP: well, vte does depend on icu, but icu shows up in its sysroot through indirect dependencies, rather through direct dependency in vte recipe May 05 20:25:16 I thought hashequiv is able to handle this? May 05 20:25:31 kanavin_home: right, and hash equiv won't handle this too well :/ May 05 20:26:19 JPEW: a nice new corner case to think about... May 05 20:26:28 yeah, we can list icu in vte recipe, but then we should populate sysroots only with direct deps May 05 20:27:24 kanavin_home: right, its defining "direct" that is hard May 05 20:29:32 RP: or then hash equivalency for sysroots should consider not only the task output, but also all of its inputs - I am not sure but I suspect this isn't happening? May 05 20:30:03 kanavin_home: doesn't work like that... May 05 20:32:23 kanavin_home: at a guess, lets say its harfbuzz which is the indirect dependency on icu. It links against it so it needs to be in the sysroot but between these two versions of icu, harfbuzz didn't change its binary. May 05 20:33:27 kanavin_home: that would mean the hardbuzz has the same output. vte silently links but the input dependency isn't detected and then we have this problem May 05 20:34:42 although harfbuzz does have versioned functions in it so it has to change May 05 20:35:11 kanavin_home: I can kind of see the problem but not quite May 05 20:36:07 If vte does actually depend on icu (e.g. a change in icu requires vte to rebuild), I would think icu has to be in DEPENDS? May 05 20:38:41 JPEW: vte -> gtk3+ -> pango -> freetype -> harfbuzz May 05 20:39:11 ah, vte -> gtk3+ -> pango -> harfbuzz May 05 20:39:36 I suspect pango didn't change even though harfbuzz did May 05 20:41:04 yes, I think that's what I saw in local build May 05 20:41:13 pango does not depend on icu May 05 20:41:20 I think we follow the chains since gtk headers probably needpango headers which need harfbuzz etc May 05 20:41:48 but we probably don't need all the libs themselves, only the headers from non direct dependencies ? May 05 20:42:51 New QA test to detect linking against non direct dependencies? May 05 20:43:06 RP: Ya, is that possible? May 05 20:53:23 kanavin_home: my stale build here doesn't have this linkage :/ May 05 20:55:06 kanavin_home: I guess this is a change in the new vte? May 05 20:56:31 RP: possibly, I only tried with the new vte May 05 20:57:39 but it's clearly there: May 05 20:57:39 akanavin@ubuntu1804-ty:~/poky/build/tmp/work/core2-64-poky-linux/vte/0.60.2-r0/image$ ldd usr/lib/libvte-2.91.so.0.6000.2|grep icu May 05 20:57:39        libicuuc.so.66 => not found May 05 20:57:48 and this on a branch that has icu 67! May 05 20:59:04 kanavin_home: ldd usr/lib/libvte-2.91.so.0.5800.3|grep icu shows nothing May 05 20:59:28 kanavin_home: basically a new dependency was added and the system has no idea it needs updating May 05 20:59:46 kanavin_home: I think we need some QA test to detect this happening May 05 21:03:09 RP: yes. Certainly better than populating sysroots only with direct dependencies which will break half the world. May 05 21:05:38 kanavin_home: right May 05 21:05:58 kanavin_home: meanwhile we need to add the dependency in master-next to unbreak the builds... May 05 21:06:21 RP: yes, do you want a corrected patch? May 05 21:07:38 kanavin_home: vte merged so it will be an update I think May 05 21:11:50 RP: patch sent May 05 21:12:05 I guess you can re-introduce icu 67 too May 05 21:13:09 kanavin_home: thanks, and yes, I will May 05 21:15:55 RP: otherwise the patchset looked pretty good, lots of green I think May 05 21:17:15 Oh perf.... you're not going to be reproducible willingly are you May 05 21:21:14 kanavin_home: yes, hope so! May 05 21:21:31 JPEW: you're breaking up, can't make out the transmission... May 05 21:41:22 RP: perfs going to be a bit of a pain to make reproducible May 05 21:54:31 JPEW: :( May 05 21:54:45 JPEW: Is upstream interested? May 05 21:55:47 RP: Not sure yet, most of the fixes are fairly simple, so I suspect they won't be too bad.... but I can't figure out how to keep bison from making the generated header guards encode the whole path May 05 21:56:28 You get things like this: #ifndef YY_EXPR_PROJECTS_LINUX_TOOLS_PERF_BUILD_UTIL_EXPR_BISON_H_INCLUDED May 05 22:07:03 JPEW, whee - that is pretty fugly. :-/ May 05 22:17:30 JPEW: :( May 05 22:20:32 FWIW, external drives do work so long as you format them for ext4 May 05 22:47:50 mmort, you don't say? May 05 22:54:39 I had to learn the hard way, thanks to some help from boo. May 05 23:54:35 I built a Yocto toolchain with support for Boot to Qt as described here: https://doc.qt.io/QtForDeviceCreation/qtee-custom-embedded-linux-image.html . Following that, when I try to run the configure-qtcreator.sh script it comes with, I get an error saying Cannot find 'sdktool' from Qt Creator May 05 23:55:40 This is on Ubuntu 18.04 **** ENDING LOGGING AT Wed May 06 03:00:05 2020