**** BEGIN LOGGING AT Tue Jan 12 02:59:57 2021 Jan 12 05:53:17 Hello, I have been trying to run a build on the [paule/rpurdie-license-experiments-osls] branch. I haven’t been successful due to some errors. The errors are very similar to one already reported on a mailing list. Sadly no solution was provided. My system is Ubuntu 20.04. When I run the build I get the error message: ERROR: qemu-native-3.1.0-r0 do_compile: oe_runmake failed Jan 12 05:53:17 Attached is a link to the same issue reported previously in a mailing list: Jan 12 05:53:17 https://www.yoctoproject.org/pipermail/yocto/2019-October/047013.html Jan 12 05:53:44 P.s the shared log in the attached report has the exact same issues as my current log. I will upload logs if required. Thank you for helping Jan 12 05:56:05 I'm using the poky-contrib repo Jan 12 06:15:29 Yocto Zeus has both Python 3.x and Python 2.7.x. How can i exclude python 2.7.x from the image? Jan 12 07:46:32 Hello:)  How can I see the logs of yesterday discussion please ? Thanks ^^ Jan 12 07:52:22 Chrys: https://www.yoctoproject.org/irc/ Jan 12 07:52:43 halstead: looks like IRC logs aren't working for 2021 ^^^ Jan 12 07:56:20 Yep ! So i don't know if i get answered yesterday x) Jan 12 07:58:02 Chrys: let me check my own logs Jan 12 07:59:16 Chrys: no answers Jan 12 07:59:30 Chrys: IMHO you should explain better your issue Jan 12 08:00:06 Thanks mckoan Jan 12 09:09:31 Siva38: just don't put it in the image? Jan 12 09:22:27 idadel: on which branch are you developing? qemu is 5.2.0 on master Jan 12 09:40:30 qschulz: paule/rpurdie-license-experiments-osls Jan 12 09:46:04 hello, I'm trying to build some userspace applications and I get the following message: "...arm-zaku-linux-musleabi/10.2.0/ld: cannot find -lgcc_s", in total these are missing: "crti.o, crtbeginS.o, -lgcc, -lgcc_s, -lc, -lgcc, -lgcc_s, crtendS.o, crtn.o". The linker seems to be broken. Is there something wrong with my makefile or .bb recipe? Jan 12 09:49:42 justas: the latter, usually. espcially if you're using a handcarved makefile, then chances are roughly 100% (give or take some) Jan 12 09:54:14 idadel: ah right, forgot you already mentioned it sorry. It's apparently based on thud according to meta-poky/conf/distro/poky.conf. Jan 12 09:54:46 I'm not sure it's worth debugging right now since thud does not support Ubuntu 20.04 officially Jan 12 09:55:05 so, either rebase on a branch that supports Ubuntu 20.04 officially, or maybe use containers Jan 12 09:56:07 maybe RP did build the branch on a decently recent distribution, and might be able to help Jan 12 09:56:45 for containers, kas, or pyrex are usually the go-to, I've personally used neither of them Jan 12 09:57:37 also, those bugs might be fixed in qemu itself or glibc or something so wandering through the respective git repo/mailing lists and try to find patches you can backport is also an option Jan 12 10:00:29 what could be the debugging steps to find out what part of the recipe is breaking the linker? Jan 12 10:11:02 justas: are you using a handcarved makefile? Jan 12 10:13:16 yes, it's not from autotools. Jan 12 10:16:06 justas: any particular, real technical reason for that? (other than "i don't like build systems"?= because chances are that migrationg to meson, cmake, autotools will fix stuff properly. Jan 12 10:18:28 Zeus has both Python 3.x and Python 2.7.x. is there anyway to remove python 2.7.x from the rootfs image? Jan 12 10:18:28 justas: else, the debugging steps are basically: make sure that your makefile has basically nothing hardcoded, especially _no_ _absolute_ pathes and no binary names, anywhere. Jan 12 10:18:45 Siva38: just do not put it into the rootfs? Jan 12 10:19:21 it's a kernel module from a big vendor, they apparently do things different. :/ ok thank you, I'll check it out :) Jan 12 10:19:39 justas: even the so called "big vendors" ship crap. Jan 12 10:20:09 RP: Looking at this failed build: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/2938 Jan 12 10:20:28 RP: I see it has PACKAGE_CLASSES = "package_rpm package_deb package_ipk" in the write config stage Jan 12 10:20:44 RP: Am I right thinking the rootfs is built with the first entry on that list, i.e. RPM? Jan 12 10:21:29 paulbarker: yep, first one is actually used in the process, others are just to create package streams. Jan 12 10:21:39 Actually, yes, that's what the comment in my local.conf says Jan 12 10:22:31 So the rootfs will be built with RPM. And the "rootfs_ipk: allow do_populate_sdk in parallel to do_rootfs" patch won't have any affect here Jan 12 10:23:07 s/affect/effect/, I need more coffee Jan 12 10:23:55 s/coffee/beers/ Jan 12 10:24:02 The build failure is almost certainly due to my patches then and not that rootfs_ipk patch if the rootfs isn't being built with ipk Jan 12 10:24:30 LetoThe2nd: I'll save the beers for later Jan 12 10:24:46 Siva38: something is pulling python2, so you need to either configure this thing to not use python2 or remove the thing(s) that need python2 from your image. Easiest way is to just remove the python2 recipe and see what fails to build Jan 12 10:25:04 and iterate over and over again until it does not fail anymore and then you're good to go Jan 12 10:25:10 paulbarker: i've been chasing sig mismatches on esdk generation for a krogoth based thing for days now. such fun for all of us. Jan 12 10:27:34 I'll kick off a local build with a roughly similar config to the failing autobuilder one and see what happens Jan 12 10:27:42 paulbarker: correct, I should have realised that earlier. It is your series then :( Jan 12 10:28:13 RP: Is there a command to check if a path is in the pseudo db? Jan 12 10:28:36 paulbarker: not directly, no Jan 12 10:28:46 The build failure is probably non-deterministic but hopefully the pseudo db state after do_image_wic finishes is deterministic Jan 12 10:29:13 paulbarker: right. I did have patches to hack status checks onto the DB Jan 12 10:29:44 RP: The way wic invokes pseudo when wic is already running under pseudo does always worry me Jan 12 10:30:10 paulbarker: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=73b183bd81bb47181ea622389de5675f63848ac7 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=34853d4bcca9dd4fb457706c7cc7d0b7c8384a12 Jan 12 10:30:23 ok, let me remove ./poky/meta/recipes-devtools/python/python_2.7.17.bb, ./poky/meta/recipes-devtools/python/python-native_2.7.17.bb and check Jan 12 10:30:25 paulbarker: may give you inspiration Jan 12 10:30:54 RP: Ok, I'll let this build run locally and then see what I can do with the results Jan 12 10:30:58 paulbarker: it worries me too :/ Jan 12 10:31:11 RP: Feel free to back my patches out of master-next for now Jan 12 10:35:42 RP: Patches 1 & 3 of the series should be relatively un-controversial Jan 12 10:35:59 The rest may need some re-work once I've found out what's corrupting the pseudo db Jan 12 10:45:36 paulbarker: will do, these things can be a bit tricky Jan 12 10:49:53 RP: hi Jan 12 10:50:44 again about PRIVATE_LIBS, say a recipe foo.bb gives the unversioned, no soname, bar.so Jan 12 10:51:37 is it pointless to add the lib to RPROVIDES_{PN} isn't? Jan 12 10:51:54 the shlibs resolver would not pick it up Jan 12 10:55:35 afais the oly way to force it and fix the [file-rdeps] QA would be ASSUME_SHLIBS bazooka which doesn't sound right with private libs Jan 12 10:56:21 atm we added the build/runtime dependency in the recipe needing it Jan 12 10:56:48 (it's a v3driver providing gles2) Jan 12 11:53:04 ant__: Adding an INSANE_SKIP is probably fair in this case Jan 12 12:43:14 Hello guys. I need an high level suggestion.. I will have two boards with the same SoC chip but with different external devices and FPGA IP cores. What it was asked me is, if it possible, to have one main project that can build the proper Linux distro for each board without the need to menage two separate projects. How can I do that in yocto ? I've Jan 12 12:43:15 seen someone using different MACHINE and others using multiconfig. Which is in your opinion the best way to do that ? Jan 12 12:46:58 are the different external devices accessed via the SoC? Jan 12 12:47:03 or via the FPGA? Jan 12 12:47:29 RP: eh, yes Jan 12 12:47:32 thx Jan 12 12:48:56 qschulz, both of them, so the DT will be different and probably also the kernel configuration file. Jan 12 12:53:45 thekappe: different kernel configurations definitively mean two distinct MACHINE configurations. Jan 12 12:57:24 thekappe: "It depends" Jan 12 12:58:19 if you can have the same kernel but different device trees and you can detect from u-boot which board you're booting, then embed all dts in the fitimage and select the correct configuration at runtime Jan 12 12:58:46 you could also put all FPGA FW in the same fitimage and select which one to flash from there Jan 12 12:59:03 there/uboot Jan 12 12:59:12 "same kernel" != "different kernel configuration files" Jan 12 12:59:57 LetoThe2nd: well... it depends :) if one board needs a more featureful configuration than the other, maybe you can just use the featureful configuration for the other board too Jan 12 13:00:28 but then they aren't different anymore. QED. Jan 12 13:01:13 LetoThe2nd: which was the point I was trying to raise. It's not because you want more features for one board than you want to exclude those features from the other board Jan 12 13:01:35 especially since most of the config nowadays for most people/vendors are just enabling drivers Jan 12 13:01:43 yeah, i know what you mean. Jan 12 13:02:34 thekappe: and you'll need multiconfig anyway :) Jan 12 13:02:43 LetoThe2nd, qschulz, thanks for the hints Jan 12 13:02:44 to build your FPGA FW Jan 12 13:03:10 @qschulz also because I need the overlay feature Jan 12 13:03:13 so all in all, you just have to figure out if you want to share the same MACHINE for your two boards (which is doable in some cases, but most often not) Jan 12 13:03:22 thekappe: fitimage supports dt overlays Jan 12 13:03:30 woha Jan 12 13:03:34 well, u-boot supports dt overlays sorry Jan 12 13:04:00 not sure if you can put them in the configuration node though, might need to handle the logic from u-boot side Jan 12 13:04:20 the overlay and fpga fw will be on a dedicated partition Jan 12 13:04:31 but I've done it before by using bootm ${loadaddr}#additionnal-dtb#additional-dtb Jan 12 13:04:54 and will be used after the kernel has booted Jan 12 13:04:55 thekappe: then you can use fdt support in u-boot Jan 12 13:05:13 since they are related to a specific application package Jan 12 13:05:14 to patch the dtb you loaded Jan 12 13:05:35 why applying them after the kernel has booted? Jan 12 13:07:50 I really don't know. The guys told me they do so Jan 12 13:08:57 I didn't know that u-boot manages dtbo files Jan 12 13:11:31 this channel is fu**** amazing Jan 12 13:50:18 hi guys, i'm running a PR service (bitbake-prserv) but I'm getting a lot of this issues from time to time in my ci/cd: Jan 12 13:50:18 `ERROR: mc:qt5122:gstd1.0-0.6.2+gitAUTOINC+3526d0ffdb-r0 do_package: Can NOT get PRAUTO, exception [Errno 111] Connection refused` Jan 12 13:50:18 Is there anything specific you can recommend to get rid of this errors? I don't know if they happen because of multiple access at once... or the machine running the PR Server is busy/not responding... any idea? Jan 12 13:55:19 dagmcr: its likely some kind of performance/scaling issue :/ Jan 12 13:56:09 dagmcr: what kind of scale is this running at? how many workers pointed at the prserv? Jan 12 14:15:19 hello, while compiling a 3rd party out-of-tree kernel module, I get error: the frame size of 1192 bytes is larger than 1190 bytes [-Werror=frame-larger-than=] Jan 12 14:15:53 is there a standard way to tweak the GCC compiler flags under Yocto to work around this? Jan 12 14:23:54 Hello all:)    The situation : I want to remove a RDEPENDS within a packagroups which is in the 2nd highest layer. In my first highest layer, i put un RDEPENDS_remove of this package that is in the packagegroup... Problem. It's say that "nothing provide" that package. Which is normal as I removed it. I Check with bitbake -g .... No dependencies Jan 12 14:23:54 with it... If i don't use the packagegroup and I manually add one by one the package except the one i want to remove, everything is fine.... Any workaround? Jan 12 14:25:36 I want to remove a package which RDEPENDS* Jan 12 14:25:54 Chrys46: RDEPENDS_${PN}_remove Jan 12 14:26:03 yeah Jan 12 14:26:10 bitbake -e is here to help Jan 12 14:26:46 I already have 3 packages on my REDEPENDS_${PN}_remove, when i had the fourth one, it doesn't work. Jan 12 14:26:50 but something strange is... Jan 12 14:27:03 give us what you're doing Jan 12 14:27:34 for now it seems your issue is not with RDEPENDS_${PN}_remove but with one partiular element of your packagegroup Jan 12 14:27:34 if i delete the first line of this RDEPENDS_remove.... Jan 12 14:27:37 it works Jan 12 14:27:42 give us the line Jan 12 14:27:49 it's another package Jan 12 14:28:13 give us your too RDEPENDS_${PN}_remove Jan 12 14:28:17 two* Jan 12 14:49:10 qschulz sorry, i have been busy Jan 12 14:50:41 for example : RDEPENDS_${PN}_remove = "proftpd dhcp-client ifupdown" Jan 12 14:51:08 what would be the second _remove then that would fail this one? Jan 12 14:51:35 https://controlc.com/17ab7bca Jan 12 14:51:44 and that is the RDEPENDS Jan 12 14:51:53 From the RDEPENDS, i want to remove fuse Jan 12 14:52:06 So i put it to RDEPENDS_${PN}_remove Jan 12 14:52:14 ( because it's a bbappend of this file ) Jan 12 14:52:26 and that fail Jan 12 14:52:53 if i remove the first package of the REMOVE, it works... Jan 12 14:53:34 or the second, or the third Jan 12 14:57:15 Chrys46: can you put a package per RDEPENDS_${PN}_remove? (basically have one _remove per package?) Jan 12 14:57:49 mhh what's your guessing? Jan 12 14:58:01 some special character that mess up? Jan 12 14:59:35 Chrys46: i don't know, just trying out my luck :p Jan 12 14:59:48 I've already done that Jan 12 14:59:53 multiple _remove on a single variable are supposed to not work anyways... Jan 12 15:00:03 And it removes all the time the first 3 removes Jan 12 15:00:26 I mean, i have 4 x times RDEPENDS_${PN}_remove Jan 12 15:00:29 Chrys46: can you give us the lines above the line starting with RDEPENDS_${PN}= in the output of bitbake -e ? Jan 12 15:00:35 LetoThe2nd: What? sources? Jan 12 15:01:20 LetoThe2nd: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#removal-override-style-syntax Jan 12 15:01:23 https://theyoctojester.info/session_14/main.html comment by Chris Jan 12 15:01:46 LetoThe2nd: nah, that's a different thing Jan 12 15:02:00 it's a way to make it possible for other bbappends to cancel your _remove Jan 12 15:02:00 yes. maybe it works when everything is in the same recipe? Jan 12 15:02:21 but if the removes are spread out i don't think they work Jan 12 15:02:32 there's no reason for them not to work Jan 12 15:02:45 but eh, happy to be proven otherwise :) Jan 12 15:02:55 in any case, one of us will have learn something today :) Jan 12 15:04:31 yeah Jan 12 15:04:31 Chrys46: the output of bitbake -e will give you the history of how the variable was set, so this is usually a very good place to start looking when things are going not the way you expected Jan 12 15:04:45 but i'm so old already that i will instantly forget again! Jan 12 15:07:21 LetoThe2nd: I'll remind you until the day I'm too old too don't worry Jan 12 15:08:15 thanks mate Jan 12 15:10:20 Where can I list all available packages to install with IMAGE_INSTALL? Jan 12 15:11:04 Sponge5: maybe oe-pkgdata-util Jan 12 15:12:47 qschulz trying to check :) Jan 12 15:12:57 LetoThe2nd: huh, networkmanager is not there Jan 12 15:14:01 Sponge5: hum, so what? Jan 12 15:14:17 If i see the remove done before the "add" Jan 12 15:14:21 it will add? Jan 12 15:16:11 LetoThe2nd: idk, thought it was a pretty basic package. So if it's not there I have to find/make a recipe to include it in my image, right? Jan 12 15:17:04 Sponge5: its a package provided by meta-openembedded/meta-oe. so it is supposed to be there if you have added that layer, and to not be there if you haven't added it. Jan 12 15:18:21 hi there Jan 12 15:18:50 I've enabled debug-tweaks for passwordless root login on my dev board, but I'm still getting: login: can't set groups: Operation not permitted Jan 12 15:18:52 any idea? Jan 12 15:19:57 LetoThe2nd: got it, thanks. Interesting that noone has asked this on SO yet Jan 12 15:20:04 Chrys46: _remove is final, it's the last thing to be done so no it shouldn't matter, but obviously bugs are possible Jan 12 15:20:40 Sponge5: http://layers.openembedded.org/layerindex/branch/master/recipes/ for recipes Jan 12 15:20:55 @v0n I think that happened to me when I also enabled readonly root filesystem without symlinking /etc/shadow etc to persistent storage. So, did you enable read only rootfs? Jan 12 15:21:12 but obviously this does not allow you to look for packages, only recipes Jan 12 15:22:59 i've done a show-layers Jan 12 15:23:06 And my bbappend is there Jan 12 15:23:24 Btw, it seems that... i don't see the RDEPENDS_${PN}_remove Jan 12 15:23:37 on the bitbake -e Jan 12 15:23:50 emrius: my distro is quite simple at the moment, no packages, nothing. I've only added debug-tweaks to my machine definition Jan 12 15:23:50 the bbappend is in a different layer in a highest layer Jan 12 15:24:42 Chrys46: you won't see an entry for RDPEENDS_${PN}_remove, same for _append Jan 12 15:24:57 Yocto builds variables directly but give you the history Jan 12 15:25:12 if the bbappend is parsed (thus, found by yocto), the priority does not matter Jan 12 15:25:24 Ok so he know thats there is a "remove" and it shows me the final result then? Jan 12 15:25:32 Chrys46: more or less Jan 12 15:25:44 because sometimes you have machine specific variables Jan 12 15:25:56 so if i see my package still in RDEPENDS_${PN} .. Jan 12 15:26:07 mmmmm... actually no, you're right, it is final result you see in the variable Jan 12 15:26:19 Chrys46: you're screwed :) Jan 12 15:26:24 And i see that some of the package have been removed by RDEPENDS_${PN}_remove, but not others..; Jan 12 15:27:41 well, there might be other stuff going on, in which case, you'd need to send us the commented lines above RDEPENDS_${PN} or try to make sense of the history yourself if you don't want to share it Jan 12 15:30:40 oh Jan 12 15:32:55 (from the output of bitbake -e) Jan 12 15:33:53 it have been removed Jan 12 15:33:59 i checked the comment and not the variable xD Jan 12 15:34:13 My guessing is that another package depend it Jan 12 15:34:23 where is the log of the bitbake i've done to see which task failed? Jan 12 15:37:23 Maybe caching problems? Jan 12 15:40:25 where are the signatures respectively basehashes egnerated? Jan 12 15:40:50 (which files/functions to look at?) Jan 12 15:41:07 I would like to know if anyone develops using the native SDK? How am I suppose to use the libraries in there? Do I need to source the environment and _not_ load the OEToolchainConfig.cmake? Jan 12 15:44:50 Ok, it was a caching problem Jan 12 15:45:21 why is sstate putting fuse if i don't ask for? Jan 12 15:46:31 Chrys46: you need to give us more context, we don't have access to your building machine, error logs or config :/ Jan 12 15:46:43 so the problem was the Sstate cache Jan 12 15:46:51 i cleansstate of the packagegroup Jan 12 15:47:08 Chrys46: you have bigger problems if you need to cleansstate a packagegroup Jan 12 15:47:18 ah, there is a bug open for packagegroups :/ Jan 12 15:47:27 @qs Jan 12 15:47:30 ah! thanks RP for chiming in :P) Jan 12 15:47:43 Chrys46: well there you have it, a bug :) Jan 12 15:47:53 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7298 Jan 12 15:48:20 I'm guessing its related to that Jan 12 15:50:04 * paulg wonders if there is a good example of package "b" that somehow makes use of knowledge that package "a" has some or all of what it needs already... Jan 12 15:50:15 LetoThe2nd: have you looked into the TMPDIR/stamps directory? Jan 12 15:50:36 ...or to go one step further, a meta-package that primarily exists just to "prime" the downloads dir with content. Jan 12 15:50:43 RP: not entirely clear but can't rule it out Jan 12 15:50:55 Ok we use jenkins Jan 12 15:51:04 and we take the sstate on a server Jan 12 15:51:10 when i clean, i do it locally Jan 12 15:51:17 but still i take it from the server Jan 12 15:52:04 mmmm... but the sstate-cache signature should not match for the one you take from the server Jan 12 15:52:08 I shall update our build machine. It's DELL Optiplex 7010 from 2014. CPU is a octocore i7-3770 CPU @ 3.40GHz. We're maxing RAM out to 32GB. Shall I go for a SATA (about 500MB/s read&write speed) or a PCI-express one (3000 to 6000MB/s readwrite speed)? Jan 12 15:52:27 For the SSD Jan 12 15:53:28 paulg: what is your prime recipe providing for other recipes? in other words, can't you have a recipe which compiles everything you need in one recipe only? Jan 12 15:53:45 if not, can't you just create your prime recipe and add it to the DEPENDS of other recipes? Jan 12 15:54:04 manuel1985: NVMe drives are worthwhile if you have a CPU with enough cores Jan 12 15:54:34 when a task is done, can we know from where the "work" have been taken? Jan 12 15:54:43 paulbarker: Enough being considerably more than 8 cores I suppose? Jan 12 15:54:49 like if it was taken from those sstate or whatever Jan 12 15:54:51 manuel1985: I'm running a 6c/12t machine and an 8c/16t machine, both with NVMe drives Jan 12 15:55:30 Chrys46: if taken from sstate-cache, you won't have a new file in ${WORKDIR}/temp/log.do_ Jan 12 15:55:31 I think if you have at least 12 threads it's worthwhile. If there's a tradeoff to be made below that, spend the extra money on CPU not disk Jan 12 15:55:33 YPTM - armin is on Jan 12 15:56:40 qschulz i needed to check de timestamp of the file right? Jan 12 15:56:48 to make sure he have really made the task Jan 12 15:57:08 or just remove the ones you have currently Jan 12 15:57:25 the ${WORKDIR}/temp dir can be safely removed Jan 12 15:57:31 if i remove, and no news one, it means sstate cache? Jan 12 15:57:50 yup Jan 12 15:57:53 ok i see Jan 12 15:57:53 I'm just not sure if that old cpu is a bottleneck. But my thinking is that a full build will run only at night when build time doesn't matter, and builds during the day will be incremental, that is we might benefit from fast disk access more than cpu power Jan 12 15:57:58 thanks you Jan 12 15:58:34 have a good day qschulz Jan 12 15:59:12 Chrys46: you too, please don't forget to keep us updated or open a bugreport if you find something odd Jan 12 15:59:39 qschulz, yeah - the prime will be a depends of the children for sure.. I was more concerned if it was allowed for pkg B to make direct references to content in the downloads dir from pkg A, or if that violated some kind of fetcher rules. Jan 12 15:59:58 qschulz no prob Jan 12 16:00:17 basically I think I just have to try my idea and see what breaks. :-P Jan 12 16:00:57 paulg: either you want something like work-shared that is used by the kernel recipe, or abuse DEPENDS with a custom SYSROOT_DIRSA Jan 12 16:01:34 paulg: otherwise if the concern is just "not download from the network twice the same tarball", that should alreayd be handled by the fetcher IIRC if you have the exact same URLs Jan 12 16:01:50 if it's "do not untar the tarball twice", then it's a different thing Jan 12 16:08:33 qschulz, ah but there is the rub. It is 2021 and I'm not using tarballs. I'm using git, and want to capitalize on the fact that objects from A are used in B (like git clone --reference...) Jan 12 16:09:07 Separate projects, but a fair chunk of shared history. Jan 12 16:09:56 paulg: what about subpath in the git fetcher? https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git Jan 12 16:10:12 you would clone only what you need *if you have separate directory for your projects) Jan 12 16:11:20 thanks for the pointer. I'll have a read of that once I get some boilerplate test framework in place. Trying to steer clear of the fetcher as much as possible, of course. Jan 12 16:11:39 I've heard small children have strayed in there and never been seen again. Jan 12 16:12:31 zeddii was fighting with it once. Didn't see him for a year and he came back with grey hair. Jan 12 16:14:08 paulg: I'll let you do it by yourself then, too young still to have grey hair Jan 12 16:44:09 If I would like to have a shared sstate-cache for all users on a unix system, where would I put it? What's the canonical location? /var/opt? Jan 12 16:53:18 manuel1985: You can put it whereever, just set SSTATE_DIR correctly Jan 12 17:02:37 Yeah I know, I just don't want to violate some agreed standards. Jan 12 17:02:42 https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Jan 12 17:03:00 JPEW Jan 12 17:03:16 put it in /srv if you want to follow a standard Jan 12 17:03:22 i live wild and free, and have /yocto Jan 12 17:03:41 renegade!!!! Jan 12 17:03:45 Some people just want to see the world burn. Jan 12 17:03:47 that's how I roll Jan 12 17:04:10 * zeddii doesnt' have a shared sstate cache. so there!!! Jan 12 17:06:14 What do I do if I want to access the same sstate-cache from several unix user accounts? Standard file permission is 644, so even if I put all the accounts into the same group only the creating one will have write access. (If I understand right.) Jan 12 17:09:09 My sstate-cache is on a read-only parition, that way it never updates and I always have to build from source.. Jan 12 17:10:16 manuel1985: change your umask Jan 12 17:10:40 group yocto, sticky bits on the parent, etc Jan 12 17:13:12 rburton: Thanks Jan 12 17:14:51 rburton, my sstate-cache is bigger than yours :) Jan 12 17:15:31 purple: sorry for the delay. 6 workers at max pointing to the same PR service. Jan 12 17:17:52 ant__: 111G /yocto/ross/sstate/ i did purge it fairly recently Jan 12 17:41:19 rburton: 601G here :) Jan 12 17:42:24 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/2941 - the warning - is that a quick fix for you or do I report to Kevin? Jan 12 17:47:05 the CI builder has 383G and thats only been up a few months Jan 12 17:47:51 rburton: we could ask michael what the autobuilder is at? :) Jan 12 17:48:27 Bets on how long it takes to actually calculate? Jan 12 17:49:10 wasn't JaMa always purging it? Jan 12 17:49:27 iirc he had some clever scripts Jan 12 17:49:38 that was for his meta-oe builder, yeah Jan 12 17:49:40 RP: I have a configuration tweak patch from him, I'll send it by EOD with some other changes. Jan 12 17:49:50 right Jan 12 17:50:01 zeddii: ok, so I could merge and this will be resolved soon? :) Jan 12 17:50:09 zeddii: might have another defconfig warning with 5.10 that a bsp is triggering Jan 12 17:52:10 RP, calculating now with a timer. Jan 12 17:52:21 RP: poky-contrib zedd/kernel has the -stable updates and the likely warning fix. Jan 12 17:54:06 zeddii: I'll wait for you to send but its good to know I can keep the change in queue :) Jan 12 18:00:42 Is f2fs still better than ext4 for (e)MMC or is it not true anymore? Jan 12 18:07:30 I use f2fs its certainly faster writes than default ext4 but you can tune ext4 to get better Jan 12 18:17:22 paulbarker: just as a datapoint, I reran that failed build and it did repeat: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/2940 Jan 12 18:52:05 where are the irc logs for 2021? Jan 12 19:00:06 laying on the forest floor? Jan 12 19:00:25 Stephano, give me a sign! Tell me what to do, cause I'm gonna get through whatever you want me too, Stephano, give me a sign! Jan 12 19:00:28 paulg: xD Jan 12 19:00:32 either that, or check the fireplace. Jan 12 19:00:52 paulg i've checked already, wasn't there Jan 12 19:25:46 ah, I was about pointing to the 'backup' courtesy of ka6sox Jan 12 19:25:48 logs.nslu2-linux.org/livelogs/yocto/ Jan 12 19:26:23 halstead, ou can grab the old logs from there Jan 12 19:26:50 these days more and more people are asking about the logs :) strange Jan 12 19:34:33 The irc logs were being collected but not published. I've fixed the publish job so they are back up at https://www.yoctoproject.org/irc/ Jan 12 19:34:45 Glad you are keeping backups available ant__ Jan 12 19:57:42 halstead, do not thank me, ka6sox instead Jan 12 19:57:57 * halstead nods. Will do. Jan 12 19:58:14 (he's keeping #oe, #kexecboot and many others) Jan 12 19:58:43 I have the yocti backups, personal backups, and now I know about ka6sox's backups. IRC data shall survive. :) Jan 12 20:03:26 one yocto, two yocti ? Jan 12 20:10:51 Yocti is the name of the little Yocto Project fluffball mascots. Jan 12 20:10:52 halstead: Error: "is" is not a valid command. Jan 12 20:16:46 abelloni, https://imgur.com/a/yruuUn1 Jan 12 20:22:07 ah ok, I have multiple of those Jan 12 20:29:06 * RP is pleased halstead linked to the "proper" ones with the ball feet :) Jan 12 20:29:31 RP, The others are impostors. Jan 12 20:30:39 halstead: Yes! There are only four 'real' models. red, yellow, blue and there is one green one Jan 12 20:31:11 green was a mock up prototype so in some ways is the original... Jan 12 20:50:47 Do you still have the green one? It would be fitting. Jan 12 21:06:55 halstead: I do, its sitting near me :) Jan 12 21:08:30 Mine are boxed up at the moment. Most of them are the feet-cutout style. I have one of the original 8 ball style if I remember correctly. Jan 12 21:09:20 Its been a long time since the ball style ones were made. We should do another run... Jan 12 21:18:10 I found mine I have a red, yellow and blue, but no green Jan 12 21:20:05 the green one is definitely the only one like that, it was a mock up for the others Jan 12 21:58:25 JPEW: is there something we can do to limit the time diffoscope spends? Its taking hours :( Jan 12 22:18:22 RP: You can limit the depth (I think....) Jan 12 22:18:29 But it would make the output a lot less useful Jan 12 22:19:05 JPEW: right, I wish it was more sensible about the kinds of diffs it produced :/ Jan 12 22:21:17 Ah... I don't think so Jan 12 22:22:02 JPEW: its slowing the builds down so much its making it effectively mandatory I fix the repro issues asap :/ Jan 12 22:22:14 e.g. diffs of this vulkan staticdevs package Jan 12 22:22:21 (its a 25MB archive) Jan 12 22:22:44 although my local system did it in 60s :/ Jan 12 22:24:00 hmm, it just shows lots of "file format not recognised" which is why its fast Jan 12 22:33:08 broken objdump on that host distro, cross one works Jan 13 01:46:01 RP: Ah, ya that would do it **** ENDING LOGGING AT Wed Jan 13 02:59:57 2021