**** BEGIN LOGGING AT Mon Nov 16 02:59:56 2020 Nov 16 07:35:20 good morning Nov 16 08:14:19 yo Nov 16 08:20:56 morning Nov 16 08:39:26 hello, yocto does not allow me to set INITRAMFS_IMAGE = "core-image-minimal-initramfs" for my armv7 kernel recipe Nov 16 08:39:36 https://pastebin.com/iqHc4J1W Nov 16 08:48:53 is there no standard image recipe in poky that is usable for initramfs that can be run on an ARM platform? Nov 16 09:28:42 I have IMAGE_INSTALL += "myrecipe". What if I have no "myrecipe" in my layer? How can I make it "recommended" to be able to build image without it without commenting out the line in my image file? Nov 16 09:29:32 dv: where do you even have that? there are recommends for distro and machine, but not for images Nov 16 09:29:55 completely unrelated, shameless plug: https://twitter.com/TheYoctoJester/status/1328268563900215298 Nov 16 09:30:41 LetoThe2nd, I have it in my image .bb file... need to make it optional if recipe file is not exist Nov 16 09:32:44 dv: sounds fishy. either your image needs it, or it doesn't. this would introduce different behaviours if a laer exists or not. I guess you can do with some black python magic, but i would strongly discourage it. plus, it tries to break the restriction of one recipe (even though just through pure exitence) affects another (the image) Nov 16 09:33:05 dv: so my gut feeling (very strong!!!) is that your line of thinking is flawed somewhere. Nov 16 09:34:28 dv: if at all, then this could go into the RRECOMMENDS for the distro your image builds for. Nov 16 09:38:17 LetoThe2nd, yes. the layer with this recipe may not exist. why yocto doesn't have this simple feature? Nov 16 09:39:21 dv: if you think that it needs this feature, then why don't you send a simple patch for the simple feature? Nov 16 09:39:46 dv: seriously, i have outlined some problems with your approach, as given pointers how to address them. Nov 16 09:40:21 dv: you could also try a cross-layer include in your image into the maybe-existing layer which adds it, and silently does nothing if its not there. Nov 16 09:40:37 dv: but still i am convinced that the approach is just plain wrong. Nov 16 09:41:11 LetoThe2nd, how whould you do this if you don't like to create one more imtermediate layer? Nov 16 09:41:31 and without python black magic? Nov 16 09:42:00 boot halts for initramfs with "Warning: unable to open an initial console" even though I have devtmpfs enabled in kernel Nov 16 09:42:12 dv: *sigh* i would not do that at all. if i bulid a speicifc image, then i expect it to have all the things that i set in IMAGE_INSTALL, and totally fail if it can't find them. Nov 16 09:43:07 initramfs is built based on configs similar to poky-tiny Nov 16 09:43:17 LetoThe2nd, thanks Nov 16 09:43:24 not sure what I'm doing wrong Nov 16 09:44:30 dv: you're trying to abuse a feature that is not there. like i said, some RRECEOMMENDS trickery might do what you want - feel free to read up and meditate on https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-RRECOMMENDS Nov 16 09:45:03 dv: but it comes at the total drawback of anybody who gets to use this will be confused. Nov 16 09:49:57 if you want to do trickery you might as well create a dummy recipe which delivers the package but fails to install in the IMAGE_INSTALL if it is used Nov 16 09:50:26 this way you can keep the IMAGE_INSTALL and you create a broken image if it is used...I might add this is really not a good idea though. Nov 16 09:50:46 ptsneves, thank you! Nov 16 09:51:01 you have an image recipe depending on a package you know will not be there it is normal that it fails. Working around that is not healthy Nov 16 09:51:26 Seems, I just have to write the manual for the users to comment-out one line in the image recipe if they are building without private layer Nov 16 09:52:09 oh and the dummy recipe can even have a bbfatal in the install tasks if it is used. Nov 16 09:52:48 there you could write out there is supposed to be a private layer providing a propper version of the recipe or a bbappen overwriting the task Nov 16 10:07:16 RP: I'd like to talk about proper design of a yarn fetcher, git suggests you'd be the right person, is that correct ? Nov 16 10:07:35 well, fetcher for bitbake, that is Nov 16 10:12:55 * LetoThe2nd just misread this as "a yann fetcher"... which is kind of funny. Nov 16 10:13:51 hey, getting people to fetch me is a nice idea to escape lockdown rules :) Nov 16 10:33:26 yann: that is probably right, yes :) Nov 16 10:39:03 RP: the problem is they store the dependencies in a package.json which can include other files, and pinned versions of those in a separate yarn.lock file. This has lead me to a nasty do_fetch stage that unpacks the source in tmpdir to run yarn there to get it to fetch the deps in its own cache (new dir under DL_DIR), and then do_unpack makes yarn use that cache. This is a first thing that would want an improvement, and for which I lack further ideas, but Nov 16 10:39:03 that's not the worst. Nov 16 10:40:49 yann: this has generally been the challenge with node, crates and so many of the modern approaches don't like to "declare" what they're doing :/ Nov 16 10:43:23 The problem I have is cleany separating the (git) fetch of the main package from the one of the deps. Today our yarn fetcher derives from GitSM (which is arguably a ad-hoc design), and only rely on the donestamp from git, which causes issues (I guess I can overload those to add by-yarn.lock-cksum donestamps ), but that won't help separate from GitSM Nov 16 10:45:22 It would be better to let the recipe specify its normal source URI in the usual way, and then add a yarnlock:// URI, but the fact that file is usually shipped in main package, and requires all those package.json files, seems to bring to a deadend Nov 16 10:48:46 yann: certainly gitsm can be used for inspiration but it did solve particular challenges submodules had so it may not be the way to solve for yarn Nov 16 10:49:35 yann: has anyone ever mentioned this upstream to the developers? Did they give any hints about how it could work? Did debian or other distros find a way to work around this? Nov 16 10:49:43 * RP is just throwing out ideas... Nov 16 10:54:03 well, on Debian side we have the dh-make packaging helper which can extract dependency information from some of those metadata, but distro policy is "only one version of each package", which translates here in "all deps must be packaged first", and there is no "recursive dh-make" I know of which would do that Nov 16 10:54:42 anyway, those tools are only helpers and they occasionally guess wrong and their output needs manual tuning Nov 16 10:56:17 the end result is that many complicated packages (eg. electron) just don't make in any distro - anyway they wouldn't be used by the devs in the target ecosystem Nov 16 10:59:10 I have no clue in the case of yarn if anyone approached them, but I'm not sure anything could be done anyway - this "independent package manager" thing seems quite trendy (did you notice Qt6 is going to have one too?) Nov 16 11:00:34 yann: sounds like debian has the same problems bitbake has then :/ Nov 16 11:00:50 yeah, everyone has them, noone packages electron :) Nov 16 11:01:28 yann: we might get to try and break new ground then... Nov 16 11:08:53 Getting packages "properly packaged" one at a time to avoid duplication maybe does not make sense for yocto anyway. Apps use things like yarn.lock or npmsw to make sure the users get the same versions of their deps as they do to make sure it will work. This is narrow-minded and notably disregards security management, and the end product is sort-of statically linked, which allows them to optimize the output somehow. Nov 16 11:11:00 I'm not sure of any major nodejs app packaged in Debian, for which we could check if there is any noticeable perf/ram-consumption downsides when compared to the statically-"linked" version Nov 16 11:11:08 yann: I thought we'd moved to a model where we tried just to ensure it was a "snapshot" of the source. The key thing wasn't deduplication but ensuring that a build in three years time would show the same thing, i.e. reproducibility Nov 16 11:11:25 yann: Have you looked at what rust is doing btw? That fetcher is out of tree but likely to merge in 3.3 Nov 16 11:11:43 did not look, will have a look Nov 16 11:12:19 yann: paulbarker reviewed it and said it seemed to be doing the right things to be mirrorable and so on Nov 16 11:12:20 the reproducibilty aspect is apparently well-handled by things like yarn.lock and npmsw Nov 16 11:13:15 * paulbarker reads... Nov 16 11:14:23 For Rust there is the `cargo bitbake` tool which parses the Cargo.toml file containing metadata, dependencies, etc and then creates a recipe from that Nov 16 11:14:43 So that parse step to find dependencies, etc happens in advance Nov 16 11:14:53 And the recipe encodes that data so the fetcher can be simple Nov 16 11:15:20 `cargo-bitbake` is written in Rust so I won't point at it but I will link a couple of recipes and the fetcher Nov 16 11:15:57 Recipe for a Rust app with dependencies: https://gitlab.com/pbarker.dev/rust/meta-rust-demo/-/blob/dunfell/recipes-demo/rust/print-rand_0.1.0.bb Nov 16 11:16:12 Fetcher: https://github.com/meta-rust/meta-rust/blob/master/lib/crate.py Nov 16 11:17:07 yann: ^^^ Nov 16 11:19:14 thx paulbarker Nov 16 11:48:39 paulbarker: thanks! It does sound like its doing a reasonable job at handling things Nov 16 11:49:49 RP: I think it's pretty good. Proposing it to bitbake itself near the top of my todo list, I'll need to write a couple of test cases for it first Nov 16 11:50:35 RP: The fact that monkey patching it in via a bbclass works did shock me: https://github.com/meta-rust/meta-rust/blob/master/classes/crate-fetch.bbclass Nov 16 11:50:52 paulbarker: it sounds like it'd be a good addition and is in reasonable shape Nov 16 11:51:08 paulbarker: they dynamic patching you can do is actually scary. I keep quiet as I don't want to encourage it Nov 16 12:49:09 Hey. I have a package that is being build and I don't seem to find where it's configured for being included in the distribution. Nov 16 12:49:09 Is there a command I can use to figure that out ? Nov 16 12:49:34 I think it's probably a dependency of something, but I can't seem to figure out of what. Nov 16 12:50:32 hello, im trying to make my own distribution based on this https://github.com/STMicroelectronics/meta-st-openstlinux/blob/dunfell/conf/distro/openstlinux-eglfs.conf Nov 16 12:52:13 i have my own layer and this conf file https://pastebin.com/mJqFqNYE Nov 16 12:53:20 but when im trying to initialize the build enviroment with "DISTRO=atlinux-eglfs MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh" i get this error message: [ERROR] No 'atlinux-eglfs.conf' file available in layers/meta-st Nov 16 12:53:22 rfried: easiest way is to either remove the recipe completely and see what fails to build, or add PACKAGE_EXCLUDE = "whatever" in your local.conf Nov 16 12:54:31 nohit: wondering if your path shouldn't just be include conf/distro/openstlinux-eglfs.conf Nov 16 12:54:41 (the include is relative to **any** layers root Nov 16 12:54:52 ok ill try that, thanks Nov 16 12:55:28 what's the name of your conf file btw? Nov 16 12:55:43 are you also sure your layer is correctly named and added to bblayers.conf? Nov 16 12:56:02 atlinux-eglfs.conf Nov 16 12:57:13 qschulz: thanks. Nov 16 12:57:13 nohit: and you've put it into meta-mylayer/conf/distro/ right? Nov 16 12:57:29 yes Nov 16 12:59:59 path correction didnt help Nov 16 13:02:41 I have libarchive depending on zstd. On another recipe X there is a DEPENDS on libarchive. I would expect that libzstd would be in the sysroot due to X depending on libarchive. The dependency even shows on the pn-depends. Even so randomly the libzstd needed by libarchive on linking is not available. Any ideas? Nov 16 13:03:28 hell guys, the dynamic patching to add a fetcher is just insanely useful (even though proper plugability would probably be preferable) - I slap myself for not thinking about it and maintaining a branch of the poky repo just for our yarn fetcher... Nov 16 13:04:04 nohit: debug their layers/meta-st/scripts/envsetup.sh script, it;s not original poky Nov 16 13:19:03 qschulz: seem that if i dont give the distro variable while initializing the build environment it works Nov 16 13:20:00 if i just change it in local.conf Nov 16 13:38:10 RP, paulbarker: I guess the approach for yarn has to be a bit different than for crate: I fear we cannot get into individual deps fetching without messing with how yarn internally manages them (of which I have near to no clue). I can see the upside of the approach, though Nov 16 13:47:47 yann: fair enough, I just thought it worth looking at. I don't know enough to help unfortunately Nov 16 13:52:51 doing something similar would be great though, I'll have a quick look just in case Nov 16 14:39:04 RP: Ah, accidentally sent that systemd patch against gatesgarth... pushed a V2 Nov 16 14:54:06 JPEW: thanks Nov 16 14:57:49 hmm what about removing mozjs from polkit dependencies by using duktape as optional patch https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35 in yocto? Nov 16 14:59:50 mcfrisk: Ya, I think that would be better long term, since it looks like systemd is moving in the direction of polkit being mandatory. However, IMHO they still have the regression in behavior when not using polkit that needs to be fixed :/ Nov 16 15:01:05 systemd requiring polkit, that ... is not good, hard to keep tone down Nov 16 15:01:26 mcfrisk: Ya, I'm not particularly thrilled either Nov 16 15:01:40 having seen mozjs double in binary sizeon rootfs in past few years, now it also affects boot times... Nov 16 15:03:55 JPEW: thanks for your patch!! Nov 16 15:04:52 mcfrisk: Ya. I *really* hope upstream takes it Nov 16 15:13:16 JPEW: hope it helps, I reviewed the patches on systemd side. thanks again! Nov 16 15:26:52 mcfrisk: Thanks! Nov 16 15:32:02 Hey guys in cmake.bbclass there is this line: echo "set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} )" >> ${WORKDIR}/toolchain.cmake Nov 16 15:32:37 This is allowing a leakage of native libraries into the compilation if for some reason the STAGING_DIR_HOST does not have the library Nov 16 15:33:07 i did a git log -S for this line but from what i see it is this way since 2010. Am i missing something? Nov 16 15:33:29 ptsneves: is that necessary to make it able to find the native *binaries*? or is that only for the libraries? binaries from the native sysroot are necessary.. Nov 16 15:33:48 is there a way to use bmap-tools to resize the last partition to completely fill the target disk? Nov 16 15:34:17 tepperson: doubtful, you have to resize the filesystem too, no? most folks just set up a service to do it on first boot afaik Nov 16 15:34:24 96boards-tools has one, for example Nov 16 15:34:47 ptsneves The point is that i do not think it is correct in any way to have the native library path getting included into a cross compilation. Nov 16 15:35:30 but that's not correct. buildsystems *often* need to run host/native tooling to do their builds, or build *for* the host and then run those built tools to cross-compile Nov 16 15:35:33 you can't fully isolate Nov 16 15:35:57 you can prevent linking against or finding headers on the host, but tools are necessary Nov 16 15:36:35 defitely. but i cannot see any reason why native libraries are needed to be included in a cross compilation gcc command Nov 16 15:36:57 kergoth: i thought wic write ./blabla/imagefile.wic /dev/whatever --resize=auto could accomplish this,(or does this only resize the partition Nov 16 15:37:13 hmm, good question Nov 16 15:43:30 kergoth the result is this Nov 16 15:43:35 | /build/tmp/sysroots/x86_64-linux/usr/bin/i686-pc-linux-gnu/../../libexec/i686-pc-linux-gnu/gcc/i686-pc-linux-gnu/9.1.0/ld: /build/tmp/sysroots/x86_64-linux/usr/lib/libprotobuf.so: error adding symbols: file in wrong format Nov 16 15:48:26 Hello, I'm attempting to override avahi-daemon.conf with a .bbappend file in my meta-layer, but I cannot seem to override the file and only seem to be able to insert files into the directory via the bbappend file. Nov 16 15:48:41 from my understanding of the documentation this seems like a cmake shortcoming. Could it be that we could put the package configs in the target sysroot and thus not need the native root path ? Nov 16 15:49:26 and the compiler of course...because otherwise cmake does not find the compiler Nov 16 15:50:33 rob_gries: I think that's a file provided by upstream, not in OE, so you can't override it that way? Nov 16 15:51:03 rob_gries: e.g. overriding a file in a bbappend only works for files provided in OE, not files installed by the recipe itself Nov 16 15:51:56 JPEW: ah that makes sense... What's the most recommended way to fix that? Nov 16 15:52:21 JPEW: this is my bbappend file if it helps -- https://gist.github.com/RobGries/9f8bdf4050ae8e73f74e790bd4fa0d84 Nov 16 15:52:58 rob_gries: install over the upstream provided file in do_install_append() Nov 16 15:53:21 rob_gries: Looks like you have a comment to that effect... Nov 16 15:54:08 JPEW: Yeah, I took it out because I was worried about the "multiple recipes affecting a single file problem" but I guess that does not apply to bbappends? Nov 16 15:55:28 rob_gries: Ya, as long as the original .bb was providing avahi-daemon.conf, replacing it with a different one in a .bbappend won't cause that problem Nov 16 15:56:08 rob_gries: see recipetool appendfile and recipetool appendsrcfile Nov 16 15:56:18 the latter for files coming from oe or the upstream sources, the latter for files on target Nov 16 15:56:22 er, the former for files on target Nov 16 15:56:29 just a convenience around the bbappend setup Nov 16 15:56:43 JPEW: Thanks, I'll try that out Nov 16 15:57:08 rob_gries: FWIW, we are also modifying avahi-daemon.conf, just with a patch on the upstream source.... it might be worth adding support for a custom avahi-daemon.conf in OE-core? Nov 16 15:57:52 note: I like your idea better than patching :) Nov 16 15:58:33 kergoth: are recipetool appendfile and recipetool appendsrcfile available in Yocto Jethro? (I know it's old, but the vendor (Qualcomm) of the BSP will not upgrade it) Nov 16 15:58:43 oof. no idea :) Nov 16 15:59:46 hi guys, I was trying to boot a yocto image from an sdcard into my embedded system and I'm having a message saying "Could not find a valid device tree" Nov 16 16:00:30 JPEW and kergoth: Thanks, I have an idea what I shall try next. Nov 16 16:00:53 https://imgur.com/JycXcnC.png Nov 16 16:01:10 what do you think could be the problem? Nov 16 16:03:47 wyre: looks like your dtb is either not existent or invalid, you should check if the DTB is on the card. Also, you should check the path of where the bootcmd 'bootcmd_mmc' is looking for your dtb files Nov 16 17:16:47 could I include some package manager in yocto? Nov 16 17:34:15 wyre: a package manager won't help with this issue though Nov 16 17:35:15 mckoan, which issue? Nov 16 17:35:16 wyre: usually the package manager is included by EXTRA_IMAGE_FEATURES += "package-management" Nov 16 17:35:30 wyre: the dtb above Nov 16 17:35:35 oh, you mean the issue with dtb, yeah Nov 16 17:35:40 no, that issue was solved Nov 16 17:35:56 wyre: great. MicroGEA is a good choice Nov 16 17:36:35 wyre: happy hacking, time to quit Nov 16 17:37:55 the problem was the U-boot couldn't find the default device tree of the kernel. But I've fixed this switching the default device tree with editenv Nov 16 17:46:00 and which package manager will be added if I use that flag in building process? Nov 16 17:48:30 depends on what you've configured. Nov 16 17:48:48 see PACKAGE_CLASSES ?= "package_rpm" Nov 16 17:48:54 in your local.conf for option. Nov 16 17:48:57 s/option/options/ Nov 16 18:19:37 zeddii, just deb and rpm classes are supported? Nov 16 18:19:49 and what about the sources? Nov 16 18:19:59 they are listed in your local.conf template. there's deb, rpm and ipk Nov 16 18:27:07 zeddii, so could I get a kind of Debian based on yocto? Nov 16 18:30:10 you could produce your own .debs, which are packaged based on the oe/yocto recipes. And you'd have your own package feed to grab packages from. The similarity is the package format, and that's about it. For updates, etc, you need to maintain your own feed. Nov 16 18:32:52 zeddii, so you could, for example, package your own kernel and manage it through the package manager? Nov 16 18:34:47 yes. of course, you picked the hardest thing to package / manage on target for upgrades :D But AFAIK in master, we have all the right changes to now have conflicting kernels, etc, if you do it via package updates. Nov 16 18:36:51 zeddii, "to now have conflicting kernels"? what do you mean? Nov 16 18:37:38 and what's the link to the repo? Nov 16 18:37:42 the way the kernels were packaged in the past, you could only have one installed at a time, and that made some upgrades problematic. I think all the update-alernatives, symlinks, etc, Nov 16 18:37:53 are right now, but I haven't done it in a while. So I can't say Nov 16 18:38:07 there's no global repo, like debian, it would be your own. Nov 16 18:38:18 the yocto mega manual discusses the setup, IIRC. Nov 16 18:38:50 oh, I ask because you said "in master, we have all the right changes ..." Nov 16 18:39:29 meaning I don't know about any older releases, since I haven't tested it. but what's in the master branch of oe-core should work. Nov 16 18:41:32 zeddii, and what's that master branch of oe-core? Nov 16 18:41:51 s/what's/where's/ Nov 16 18:42:42 if you are cloning poky to build, you are getting it as part of that (meta/ and some other directories). which I assume you are, since you asked that question. Nov 16 18:43:13 zeddii, well, I'm using the BSP provided by the manufacturer Nov 16 18:43:27 then I have no idea :D Nov 16 18:43:40 I'm sure they are bundling up some random version, but I can't comment on that. Nov 16 18:43:53 zeddii, it mainly includes a vmware image for an Ubuntu where are these files Nov 16 18:44:56 I'm considering to use the crops docker container 🤔 Nov 16 19:24:30 How is the workdir determined between machine specific packages and generic? Nov 16 19:24:46 Happy to look at the code that does this but can't find it. Nov 16 19:27:40 For instance if I check a MACHINE_FEATURE in a recipe does that change the WORKDIR? Nov 16 19:36:34 rabbit9911: yes, it looks for MACHINE specific dependencies in recipe metadata and determines it. you can also force it via setting PACKAGE_ARCH explicitly in machine. Nov 16 19:37:10 khem: thanks! Do you know where that logic is? Nov 16 20:16:14 khem: In base.bbclass I see some logic that checks the src_uri. I dont se anything that checks for MACHINE_FEATURES Nov 16 20:17:16 Would this imply that if you have a recipe that checks MACHINE_FEATURES you might want to set PACKAGE_ARCH = "${MACHINE_ARCH}"? Nov 16 20:18:41 Otherwise sharing a build directory would mean rebuilding that package for each MACHINE? Nov 16 22:33:02 zeddii: I think I've merged the wrong version of the kernel 5.10 patch. Could you send the delta I need please? Nov 17 00:24:41 v5.10 is so yesterday. **** ENDING LOGGING AT Tue Nov 17 02:59:56 2020