**** BEGIN LOGGING AT Wed Feb 10 03:04:52 2021 Feb 10 03:05:12 kergoth: hm I see Feb 10 03:05:59 was concatenating the path that was adjusted by the debug prefix map with '../../../../../../work-shared/gcc/.../foo.cc' Feb 10 03:06:11 was driving me nuts. "why is this path starting with /work-shared/?" Feb 10 03:09:06 right, perhaps use work-shared as anchor and remove everything before that perhaps Feb 10 08:39:24 Hi guys... I have sources for the kernel module recipe hosted inside the custom meta-layer... Is there a way to get git revision of the meta-layer into PV of the recipe? something like gitpkgv class? Feb 10 08:40:18 I know it is a bad practice but at the moment I cannot move that outside the meta-layer to some proper git repo... Feb 10 08:40:19 :) Feb 10 09:00:33 Good morning Feb 10 09:00:58 does anyone use or has used toaster? Feb 10 09:02:55 I have used toaster for my project but I would like to come back to command line as lots of bitbake command simply do not work once you toasted you project Feb 10 09:03:42 I need for example to do a make menuconfig and add some modules to the yocto kernel, can't do that in toaster and CLI does not play ball Feb 10 09:20:25 hello Feb 10 09:39:24 mornin' folks Feb 10 09:45:28 sorry got disconnected Feb 10 09:46:07 has anyone addressed my question while I was gone? Feb 10 09:57:06 intera91: no :) Feb 10 09:58:42 since I started using toaster bitbake does not work at all, launch any command and it comes back, does nothing and no error message Feb 10 10:02:43 gm, what proper way to create a recipe starting from a similar ? can i use "include recipe.bb" ? Feb 10 10:04:07 angelo__: that's usually done for recipes that are for the same SW but of different versions Feb 10 10:04:57 i would create a linux-xx-rt from an existing linux-xx Feb 10 10:05:17 bbappend seems not appropriate since i want the name to carry a -rt suffix Feb 10 10:05:42 angelo__: that'd probably be a valid usecase indeed Feb 10 10:05:54 qschulz, thanks Feb 10 10:06:01 though, you probably want to put common stuff in a .inc and non-rt and rt specificities in their own recipes Feb 10 10:07:15 intera91: its strange there would be no message at all. Is toaster still running in the background? Feb 10 10:07:45 tried with source toaster start and source toaster start noweb Feb 10 10:07:49 same result Feb 10 10:08:18 intera91: right, but is toaster actually stopped ? Feb 10 10:08:23 strace speaks of a SIG_DFL received by bitbake and then exited with 1 Feb 10 10:08:44 intera91: if you list the processes in memory (ps ax) do you see anything left running? Feb 10 10:09:10 intera91: the bitbake-cookerdaemon.log may give more info too Feb 10 10:09:36  ps ax | grep toaster | grep -v grep Feb 10 10:09:36    5460 ? S 0:00 python3 /home/user/workspace/poky/bitbake/bin/../lib/toaster/manage.py runbuilds Feb 10 10:11:29 ok with toaster stopped it goes a litle bit further Feb 10 10:19:21 intera91: any error now? Feb 10 10:19:37 just trying to sort out layers Feb 10 10:20:16 @RP: Layer 'networking-layer' depends on layer 'openembedded-layer', but this layer is not enabled in your configuration Feb 10 10:20:29 cannot find that layer Feb 10 10:20:58 intera91: ok, that does sound like a messed up config. openembedded-layer is meta-oe Feb 10 10:23:49 corrected, added meta-oe Feb 10 10:24:10 ParseError at /home/user/workspace/poky/meta-openembedded/meta-python/recipes-devtools/python/python-django_1.6.10.bb:16: Could not inherit file classes/distutils.bbclass Feb 10 10:27:05 intera91: at a guess that is the wrong branch of meta-oe Feb 10 10:27:29 checked out gatesgarth Feb 10 10:27:38 worked fine till now Feb 10 10:27:40 d'oh Feb 10 10:50:53 Does any body know how to install 32-bit GCC on 64-bit environment? Even manually... Feb 10 11:30:43 RP: is there some patch I could prepare? Not sure what to do with that reproducibility page :) Feb 10 11:30:52 https://www.yoctoproject.org/reproducible-build-results/?branch=master-next Feb 10 11:41:52 nacknick: your distro most likely has 32-bit packages you can download manually Feb 10 11:42:14 some distros let you install 32- and 64-bit packages side by side Feb 10 11:44:35 rburton: do you have any concrete example for 32-bit gcc? I searched on https://layers.openembedded.org/layerindex/branch/master/recipes/ without success Feb 10 11:46:04 what do you actually want to do Feb 10 11:51:14 rburton: I have RPI4 with 64-bit Yocto. I want to be able to *compile* 32-bit programs *inside* it. I managed to *run* 32-bit programs with "multilib". But not to compile Feb 10 12:23:44 kanavin_home: somehow we need to figure out which of the excluded packages we've now fixed and remove then from the exclusion list Feb 10 12:24:09 kanavin_home: not sure if we could "mine" the data from previous builds to tell? Feb 10 12:38:54 nacknick: what errors do you hit compiling for 32 bit? I think there may be problems on arm with multilib headers on target :( Feb 10 12:39:55 RP: I don't hit errors. I don't know how to compile 32-bit programs. I don't have any compiler inside 64-bit Yocto for doing so Feb 10 12:40:13 nacknick: do you have gcc on target? Feb 10 12:40:24 RP: Yes. 64-bit gcc Feb 10 12:41:33 nacknick: going from memory, I think arm toolchains don't support "-m32" so you probably need to have lib32-gcc built and installed on target Feb 10 12:43:20 RP: "-m32" is x86 flag. You probably mean "-marm". But I don't have it as well Feb 10 12:44:10 RP: There is only a very "basic" version of 64-bit GCC on target. with minimal options Feb 10 12:44:22 nacknick: right, that was my point, you need to install lib32-gcc Feb 10 12:45:14 RP: Is that a package? Because bitbake does recognize it Feb 10 12:45:18 does not* Feb 10 12:45:28 nacknick: have you enabled multilib? Feb 10 12:45:39 RP: Yes Feb 10 12:45:41 RP: we could run a test build with exclusion list disabled perhaps? Feb 10 12:46:07 kanavin_home: would probably be worth a try, then I could carry the ones we think might work in -next for a bit? Feb 10 12:46:39 RP: yep, sadly reproducibility failures are quite often sporadic, and can be fiendishly difficult to trigger on demand Feb 10 12:46:47 kanavin_home: Could we improve the code to highlight which ones on the exclude list reproduced ok? Feb 10 12:46:58 so if it 'succeeds' once, that's weak evidence Feb 10 12:47:03 kanavin_home: I know :/ Feb 10 12:47:38 kanavin_home: might help if the stats reported which ones reproduced ok but are on the exlude list? Feb 10 12:48:26 RP: right, I was thinking of that. I will revisit the code I wrote. Feb 10 12:49:29 similar to upstream version checks :) where it reports both items that fail the check but shouldn't, and those that pass the check, but shouldn't - the latter exactly allows dropping the excusions from recipes Feb 10 12:49:45 kanavin_home: exactly Feb 10 12:49:51 and the former allows adding exclusions to recipes, or fixing the check where possible Feb 10 12:50:03 kanavin_home: I'm trying to figure out how we get on a patch to improve things :) Feb 10 12:51:31 RP: Maybe I'm wrong. I'm checking lib32-gcc again Feb 10 13:07:03 /!\ this channel has moved to ##hamradio /!\ Feb 10 13:11:58 /!\ this channel has moved to #nyymit /!\ Feb 10 13:12:10 ^ spammer Feb 10 13:14:15 /!\ this channel has moved to #nyymit /!\ Feb 10 13:14:35 /!\ this channel has moved to #nyymit /!\ Feb 10 13:14:42 /!\ this channel has moved to #nyymit /!\ Feb 10 13:16:53 what will happen if I join nyymit? out of curiosity Feb 10 13:18:00 you will be brainwashed Feb 10 13:18:07 and then sold into pieces Feb 10 13:18:29 and then spam all others with that msg Feb 10 13:26:51 hello guys ! Is it possible to run bitbake and buld/clean multiple recipes in one single command ? EG bitbake recipe1 recipe2 -c cleansstate Feb 10 13:28:10 thekappe: it should work just like that Feb 10 13:28:55 whoa Feb 10 13:33:30 JPEW: I found a small but rather important couple of bugs in the debug changes Feb 10 13:41:24 Are most people deploying to ARM64 platforms developiong on and cross compiling from x86_64 systems? Feb 10 13:46:34 yes, although Yocto is nowadays being tested on ARM64 build hosts as well Feb 10 13:47:15 you do need ability to run local build to be efficient, and local arm64 hardware with sufficient CPU power doesn't exist, so far Feb 10 13:47:31 ayoung: ^^^ Feb 10 13:48:27 Not sure what you mean by that last bit Feb 10 13:48:53 "local arm64 hardware" do you mean that most people don't have that avaialble? Feb 10 13:49:43 kanavin_home, ? So no just running on a Pi (for example) and powerful machines tend to be servers? Feb 10 13:50:45 ayoung: to perform a yocto build without tearing your hair out you realistically need a lot of CPU cores, at least 16, and a lot of RAM too. Feb 10 13:51:19 kanavin_home: I've had the same curiosity too, what ARM64 platforms people might be using considering Cavium ThunderX2s are fairly cheap if you can find a motherboard. Feb 10 13:52:06 and the machine has to be on your desk, servers in cloud aren't good for platform developers, only for CICD pipelines. Feb 10 13:52:43 so the easy way out is to just get the beefiest threadripper (which is x86) you can afford Feb 10 13:53:08 yocto doesn't care, it cross compiles always, even when the host and target architectures match Feb 10 14:07:44 hetzner has some nice big dedicated hardware for cheap Feb 10 14:08:01 i burned the first box they provisioned me to death building yocto on it but the replacement seems OK Feb 10 14:08:22 had to turn off CPU usage alerts :D Feb 10 14:14:49 tgoodwin: my thunderx2 is nice Feb 10 14:15:00 tgoodwin: ampere altra if you can find one though :) Feb 10 14:18:22 What about running code? Emulators? Debugging on the embedded devices? Feb 10 14:23:56 ayoung: if you want to debug code that is architecture dependent, qemu should do it just fine. If it depends on some specific hardware, then rebuild every time or make use of devtool modify+devtool deploy-target Feb 10 14:24:23 rburton: the altra -- wow. There's an anandtech review showing some serious performance there. I've checked in on this only occasionally to see if there's a good option for an inexpensive workstation. Like kanavin_home suggests though I fall back to x86 and ryzen at that point in the search every time. Feb 10 14:25:06 tgoodwin: the honeycomb lx2k is a lot cheaper but its not giant build server material like the tx2 or altra Feb 10 14:25:55 Right, I saw a review of that one last year indicating it's a little bit of a challenge to get going with a standard distro but also rather impossible to brick it given that you have to compile the bios yourself. Feb 10 14:40:46 tgoodwin: last time i looked you can get a prebuilt edk2 and then just boot normally Feb 10 14:41:06 they're working towards systemready, which makes booting as boring as it is in x86, EFI etc Feb 10 14:41:41 Oh nice Feb 10 14:42:23 tgoodwin: https://fedoramagazine.org/fedora-aarch64-on-the-solidrun-honeycomb-lx2k/ Feb 10 14:42:39 https://twitter.com/linux4kix is the guy working on the firmware Feb 10 14:46:11 Cool, thanks! Feb 10 15:41:18 RP: Not suprising. It was a pretty forumalic find and replace; I tried to do some testing but it's hard to get everything Feb 10 15:48:18 JPEW: I revised the oe-core patch to http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=7adea197c07309f64567f340a29f4cfab3535ac8 - we need the note level change or important output info disappears Feb 10 15:48:38 JPEW: I want to get rid of that function but its for another patch and we need a way to fix the output from unittest Feb 10 15:49:12 JPEW: Compare https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/1792/steps/12/logs/stdio to https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/1794/steps/13/logs/stdio Feb 10 15:49:59 JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=65a13a8625f35e0da31728a99a0dcd40bf080fd8 was the other issue, highlighted by tests that check for certain info in the logs which went missing. No idea why we didn't see actual errors Feb 10 15:51:09 JPEW: oh, and a missed case of the make_logger_.. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=fad7f02fc8a2340f2b5b31f8ca6b2e6d9ed74dfe but I didn't need that in the end Feb 10 15:51:35 RP: Ok, ya. The info() level makes sense. We can look at ways to remove that later if we need Feb 10 15:52:32 And my grep missed the mainlogger.debug( because it was using "lvl" instead of a digit.... it wasn't a fatal error because logging.debug(1) is a valid log statement, it just prints "1" :) Feb 10 15:53:10 JPEW: I didn't see anything like that in the logs though Feb 10 15:53:38 Well, it was debug level, so you would have to have run "bitbake -D" I think? Feb 10 15:53:51 JPEW: we do output debug into the logs, just not the console Feb 10 15:53:56 Ah Feb 10 15:54:06 JPEW: well, we did until this patch :) Feb 10 15:54:24 I'm just glad the tests caught it. Took me a while to work out what was going on Feb 10 15:56:28 RP: Ya. We're slowing (if not a little painfully) improving the logging API Feb 10 15:57:37 JPEW: right, its all good, I just thought I'd better explain the issues I found Feb 10 16:07:45 Do we have any C++ literate people around who could shed any light on a potential race issue? I'm wondering what the ordering is around destructors :/ Feb 10 16:09:19 RP: I might be able to help with that, whats the example? Feb 10 16:11:22 JPEW: apt-native, writeBackMMapToFile() in pkgcachegen.cc which I think ends up calling fileutl.cc FileFd::Open() and then FileFd:Close() at some point Feb 10 16:11:55 JPEW: my question is whether the Close() can lag to garbage collection time or whether there is some kind of force ordering I'm missing Feb 10 16:12:12 JPEW: I'm not 100% sure where all the pieces fit together :/ Feb 10 16:12:49 JPEW: the bug in question is https://bugzilla.yoctoproject.org/show_bug.cgi?id=14183 - the database doesn't seem to have seen the rename() call from Close() yet Feb 10 16:13:02 JPEW: and its not determinstic, which makes me think gc Feb 10 16:25:08 JPEW: I think we could just add a Close() call into that function which would then do what the desctructor would do but when we tell/need it to and it would solve the race Feb 10 16:25:31 JPEW: but my c++ is dreadful :) Feb 10 16:27:04 to be clear, there is a file rename buried in ::Close() Feb 10 16:28:22 I guess a global array which you added this fd to, to avoid gc would be enough to reproduce it Feb 10 16:48:24 RP: I tried to add "lib32-gcc" as you suggested, it did install 32-bit GCC, but when trying to compile I get errors of include issues. such as: "/usr/include/bits/wordsize.h:40:10: fatal error: bits/wordsize-32.h: No such file or directory" Feb 10 16:55:19 nacknick: closer :) sounds like you're missing one of the headers packages. I don't know what that would be offhand though Feb 10 16:55:47 There's no deferred "garbage collection" in C++, it's all deterministic Feb 10 16:56:24 wordsize is usually the libc Feb 10 16:59:01 JPEW: so before that mmap function returns, the FileFd object's desctructor would be called? Feb 10 16:59:22 Yes Feb 10 16:59:38 JPEW: ok, thanks. That rules out that theory Feb 10 17:01:58 RP: My guess would be that some of the logic in FileFd::Close() is triggering that prevents it from doing the rename() Feb 10 17:19:00 JPEW: I wonder if its a race between a file access from a different thread and the point where the file is renamed on disk but not in pseudo? Feb 10 17:24:07 That's possible Feb 10 18:00:11 moin Feb 10 18:01:44 JPEW: there is code in pseudo to work around this, I'll have to investigate Feb 10 18:14:54 RP: this is the commit that adds same-but-excluded category to reproducibility test http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates&id=34817306eb34995cce13af7e0f450eb1e6bad16c Feb 10 18:15:11 RP: I am now running a standalone selftest here with it https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1342 Feb 10 19:17:17 Hi, in dunfell, with a recipe containing python function definitions, which version of python is used? Feb 10 19:18:51 host python? Feb 10 19:19:09 fullstop: I think python3 is used throughout for the last several releases Feb 10 19:19:30 tgoodwin: from the host or something which is built? Feb 10 19:20:03 my host is stuck at ubuntu 16.04 at the moment and a recipe is doing something with datetime which fails for older python versions. (I think) Feb 10 19:24:43 it very much looks like it uses host python3. *sad python noises* Feb 10 19:25:23 Yeah I think it would be the host version. Feb 10 19:25:53 I've gotten around this by deploying a python2 script as a -native package and then running it from the various tasks. Feb 10 19:26:53 If I install python3 on the host, can I get it included in bitbake's path before the native python? Feb 10 19:28:17 I don't know about that. I would presume it follows your PATH environment variable but I haven't tried doing that. Feb 10 19:28:48 hmm.. Feb 10 19:29:10 fullstop: it's it already using your host python3? Feb 10 19:29:38 neverpanic: it is, but I don't want to replace the host python3 since I don't know what the fallout of that will be. Feb 10 19:30:12 I would rather build python3 in this user's home directory and prefer that version over the host python version. Feb 10 19:30:25 ah, wait, you need a newer python3 than your distribution's python3, and you're wondering whether bitbake would use that if you had it installed? Feb 10 19:30:47 that should work, iff you set $PATH to include that, and ensure that the build env setup doesn't remove it again Feb 10 19:31:30 Yes, the last part of your message is my concern. :-) Feb 10 19:31:55 I guess I'll try it. Feb 10 19:32:21 if you're doing "echo $PATH", it shows up, and in the same shell "bitbake ...", it should use your python3 Feb 10 19:33:43 I'll know pretty quickly since this fails before anything even starts to build. Feb 10 19:45:42 It preserves the path. \o/ Feb 10 19:48:21 Is there a way to get only Python pyc files in yocto, to save flash? Feb 10 19:52:13 not out of the box afaik, but you could probably extend the python-related bbclass to package *.pyc in separate packages and install those instead. Feb 10 21:00:35 hi all -- systemd-container wasn't shipped with systemd-importd so I added PACKAGECONFIG_append_pn-systemd = " curl xz zlib bzip2 gcrypt importd" to my distro conf. Feb 10 21:00:38 Problem is the build still fails with: "meson.build:1265:16: ERROR: Problem encountered: importd support was requested, but dependencies are not available" Feb 10 21:00:40 without much details. Feb 10 21:38:36 vdl: The `PACKAGECONFIG[importd] = "..."` line probably needs the dependencies added Feb 10 21:49:17 JPEW: seems like the comment above it is incomplete as well: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd_247.3.bb?h=master#n144 Feb 10 21:50:05 maybe this is known, but at least libice does not package correctly with tar 1.33 on the dunfell branch. I no zstd support in my tar, so I needed to update the host tar. I went with the latest, 1.33, and it failed to package. Feb 10 21:52:02 I understand that the solution to my woes is to update the server I'm using to build. Feb 10 21:52:04 https://pastebin.com/raw/e16u65C5 Feb 10 21:52:18 With that being said, this might be a problem as distributions start to use the newer tar. Feb 10 21:53:44 Also, it was "fun" thinking about tar and how I used an old version of tar to unpack the new version of tar. Feb 10 21:56:11 JPEW: the meson log shows "Run-time dependency {libapparmor,glib-2.0,gobject-2.0,gio-2.0} found: NO (tried pkgconfig and cmake)" Feb 10 21:56:22 should I install them somehow? Feb 10 22:09:34 PACKAGECONFIG_append_pn-systemd = " curl xz zlib bzip2 gcrypt importd" works from the image recipe, not from the distro conf in fact. Feb 10 22:30:28 nah it doesn't work in fact, it's simply ignored... back to failing importd build. Feb 10 22:30:55 vdl: Ya, it probably needs apparmor added to the depends list in the PACKAGECONFIG[importd] line Feb 10 22:51:58 JPEW: I can't quite see how pseudo would mishandle this rename either :( Feb 10 22:59:41 JPEW: actually, I may have spotted something. Hmm. Feb 10 22:59:54 seebs: happen to be around? Feb 10 23:00:26 seebs: I'm wondering if rename calls need to mark the oldpath of a rename as OP_MAY_UNLINK Feb 10 23:00:33 fray: ^^^ Feb 10 23:01:16 i.e. if something called stat() on the oldpath after real_rename but before OP_RENAME Feb 10 23:05:26 oof.. yes.. it could Feb 10 23:07:33 Its calling stat() on newpath after real_rename but before OP_RENAME so the database still has oldpath in it with the now incorrect inode Feb 10 23:09:56 fray: trouble is that we're already using MAY_UNLINK for newpath so we can't use it for oldpath at the same time Feb 10 23:13:02 ah, we can, there is a file and a files function :) Feb 10 23:20:13 how do you handle LIC_FILES_CHKSUM if package doesn't contain license file? Feb 10 23:21:52 JPEW: what's the best way to add apparmor to the depends list in the PACKAGECONFIG[importd] line, patching meta-openembedded or bbappend the recipe maybe? Feb 10 23:40:36 JPEW: a green master-next :) Feb 10 23:48:04 JPEW: RP: in fact how do I add apparmor as a dependency to PACKAGECONFIG[importd]? Feb 11 01:32:56 RP: I would be inclined to send a MAY_UNLINK on an upcoming rename target. Feb 11 01:52:45 Anyone knows why eclipse yocto SDK is not supported anymore? Is there an alternative to easily integrate a yocto SDK with eclipse or similar IDEs? Feb 11 01:55:23 What process flow do you guys follow when developing a C or C++ application on a target hardware with a yocto linux image? **** ENDING LOGGING AT Thu Feb 11 02:59:56 2021