**** BEGIN LOGGING AT Wed Dec 16 02:59:56 2020 Dec 16 07:29:30 bazel, the holy grail of reproducible builds fails to build reproducibly.. palm, face Dec 16 07:31:11 good morning Dec 16 07:46:16 morning Dec 16 08:21:25 We are having some problems with our CI system where the `do_populate_sysroot_setscene: Fetcher failure` task fails because of instability in our sstate cache mirror. Bitbake is able to recover by re-building the recipe and the whole build finishes successfully. But because of this task failure, bitbake returns non-zero making our CI not happy. Is there any specific reason to have bitbake returning non-zero in this case? Dec 16 08:32:04 dsueiro: That's a known issue. I've looked a couple of times for a good fix but bitbake really assumes that the sstate mirror is reliable Dec 16 08:35:09 dsueiro: A workaround is to run `bitbake --setscene-only ${IMAGES} || true` first to fetch from the sstate cache ignoring errors Dec 16 08:35:36 Then `bitbake --skip-setscene ${IMAGES}` to build anything which couldn't be fetched from sstate Dec 16 08:35:57 I'm compiling Yocto with DEBUG_BUILD = "1" and I got error with ltrace (error: 'data' may be used uninitialized in this function) which is probably related to compiler flags. Any workaround? Dec 16 08:37:52 probably DEBUG_BUILD = "0" in ltrace's bbappend? Dec 16 08:38:19 good morning Dec 16 08:41:49 paulbarker: Thanks for the tip. Is there anything that can be made to trick bitbake in this case? Dec 16 08:45:33 dsueiro: Trick bitbake in what sense? Dec 16 08:57:45 paulbarker: for a setscene task the fetcher raise the failure as a warning or info instead of an error. I didn't have time to look at the code to check if this is feasible. Dec 16 09:02:03 dsueiro: It's feasible as a local patch, needs some more testing & discussion to upstream that change though Dec 16 09:14:29 got disconnected badly... DEBUG_BUILD = "0" helped :-) Dec 16 09:15:30 luneff: I recommend the free tier of IRCCloud to avoid that Dec 16 09:16:10 luneff: It's probably worth checking if the warning is a real problem, if there is a chance the variable may be used uninitialized and it's not just the compiler getting confused Dec 16 09:16:24 If it's a real warning fixing it in ltrace would be the way to go Dec 16 09:16:54 If not, then yes changing the flags via a bbappend may work. I'm not familiar with `DEBUG_BUILD` Dec 16 09:20:46 thank you, paulbarker :-) Dec 16 09:20:49 go-recipe: my recipe will not download external resource, what i am doing wrong? https://codeshare.io/5v9LWK Dec 16 09:22:16 chris_ber: DEPENDS is a list of Yocto packages which your recipe depends on Dec 16 09:22:51 paulbarker: i tried with this line and without Dec 16 09:23:38 chris_ber: What error do you get without it? Dec 16 09:25:16 see bottom Dec 16 09:25:43 ERROR: Nothing PROVIDES 'github.com/rakyll/statik/fs' Dec 16 09:26:53 So without the `DEPENDS += "github.com/..."` line in your recipe you still get that error? Dec 16 09:27:36 yes, i will check it again, give me a second Dec 16 09:34:17 i updated the code link, but basically: "static-server.go:10:2: cannot find package "github.com/rakyll/statik/fs" in any of:" Dec 16 09:37:15 chris_ber: You'll need to look how recipes for other software written in Go handles this Dec 16 09:37:44 yeah, but i only can find hello world examples ... Dec 16 09:40:40 chris_ber: The go world seems to be very keen on vendoring dependencies and including them in the git repository for a project Dec 16 09:41:02 E.g. https://github.com/containerd/containerd/tree/master/vendor Dec 16 09:42:13 So there may not be many examples for what you want to do sadly. Go devs are crazy Dec 16 09:42:19 by this u mean i have to download the deps and it directly to the git-repoß Dec 16 09:42:40 *add it directly Dec 16 09:43:42 That seems to be usual for things written in Go. It's not something I use though so I'm very much looking at it as an outsider and thinking "this is crazy, just point at the upstream repository and version for each dependency" Dec 16 09:44:04 I'm not too familiar with if/how bitbake can handle this Dec 16 09:44:13 òk, thx for your tips. I am new to go :) Dec 16 09:44:24 For Rust I know folks wrote a crate fetcher for bitbake which makes life very easy Dec 16 09:45:59 chris_ber: For Rust you can do something like this as the crate fetcher exists: https://gitlab.com/pbarker.dev/rust/meta-rust-demo/-/blob/dunfell/recipes-demo/rust/ripgrep_12.1.1.bb Dec 16 09:46:10 A "crate" is just a Rust library Dec 16 09:46:47 I'd love to see something similar for Go but it's not something I use or have a deep knowledge of so I'm not able to put that together myself Dec 16 11:15:18 super weird situation. i rsynv -av'ed a relatively big build directory. now the whole process of copying seems to have finished already, but the shell is completely busy cranking away with listing all files. Dec 16 11:16:39 solution: tmux detach, tmux attach. it was literally just the output that was swamped. Dec 16 11:29:32 Can I make yocto produce some overview of all the partitions there are with their offsets and sizes? Dec 16 11:31:32 We're updating from zeus to dunfell and using mender on a Jetson TX2. When we deploy a dunfell artifact, everything seems to run fine. But I still want to check to rule out problems which are there but which we just didn't face yet. Dec 16 12:10:01 kanavin_home, rburton: any idea why the patches in master-next would cause arm ptests and ltp to timeout? Dec 16 12:12:04 not off the top of my head Dec 16 12:12:07 link? Dec 16 12:13:43 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/1319 https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1348 Dec 16 12:13:48 not very helpful Dec 16 12:14:16 I'm going to have to bisect it aren't I? :/ Dec 16 12:15:04 presumably the ptest log is vanished Dec 16 12:15:11 rburton: shouldn't be Dec 16 12:15:20 wondering if it hung somewhere Dec 16 12:17:19 rburton: although I can't ssh into that machine :/ Dec 16 12:17:30 that's not a good start Dec 16 12:18:20 hm my ssh is hanging too, and i've definitely connected to that in the past Dec 16 12:18:46 rburton: I've paused it and run the build on the other worker Dec 16 12:19:07 rburton: that worker does seem to have "issues" :( Dec 16 12:19:11 I was going to try selftest on that machine today now in theory the last blocker is fixed in next Dec 16 12:19:49 rburton: I'm declining to comment on that ;-) Dec 16 12:21:01 kanavin_home: we have a definite intermittent reproducibility issue in u-boot and grub-efi btw. I merged your filter patches but I think I'll now regret it due to those :( Dec 16 12:21:33 RP: then you should add those to exception lists? Dec 16 12:21:48 RP: I don't know what could cause arm64 timeouts :( Dec 16 12:22:58 i worry about the syslinux patch as that changed what builds on arm64 but it *shouldn't* have hung Dec 16 12:23:40 It could be the worker has some issue... Dec 16 12:24:18 kanavin_home: the exception list is probably the way forward if we don't have anyone to fix them. I keep thinking I should have a look at fixing it Dec 16 12:33:39 manuel1985: the partitions are not per se generated by yocto - if at all, then by wic. Dec 16 12:38:02 LetoThe2nd: don't forget about ubi too :) Dec 16 12:38:49 qschulz: good point. Dec 16 12:43:04 manuel1985: The partition layout is controlled by the XML file used by the flashing tools in the L4T BSP. If you're keeping the same version of L4T over that update, you shouldn't have any issues, but if your're going from, say R32.3.1 to R32.4.3, you may have a problem. You can compare the layouts by generating a tegraflash image from each version and diffing the flash.xml files. Dec 16 12:48:34 RP: also please drop opkg update as it has a ptest regression Dec 16 12:51:47 kanavin_home: right, its on my don't merge list Dec 16 12:52:24 kanavin_home: gone locally now Dec 16 12:54:15 RP: I couldn't reproduce the AUH failures locally, but I re-started AUH to check once more, and it failed the same way. So I'm going to try the exact sequence that AUH is doing. Dec 16 12:54:47 kanavin_home: I can just about see how it could happen with the change as I mentioned last night Dec 16 12:54:58 kanavin_home: less sure how to fix it Dec 16 12:55:04 * LetoThe2nd feels very auhbombed! Dec 16 12:55:32 LetoThe2nd: Got it, just sloppy wording ;) Dec 16 12:55:55 RP: that is what I tried, and os-release rebuilt correctly. But maybe you could also try something locally? Dec 16 12:56:35 manuel1985: nah, its not about the wording. just as madisox pointed out, there's often custom add-on stuff that does things like this. hence its really needed to go digging first which mechanisms are actually being used. Dec 16 12:57:43 madisox: So you're saying everything boils down to the flash.xml in the tegraflash.{zip,tar.gz}? That's the point of truth? Got it. Unfortunately we are indeed going from L4T 32.3.1 to 32.4.3. But I'm gonna check that flash.xml now. Dec 16 13:01:50 LetoThe2nd: So you're saying that sometimes something else is used for image creation instead wic? Dec 16 13:03:02 manuel1985: bingo. Dec 16 13:10:49 kanavin_home: reproduced. "bitbake os-release" then "vi documentation/tools/update*; git commit", then "bitbake os-release -C install" Dec 16 13:11:29 idea being to commit something which doesn't cause a reparse, then rebuild it Dec 16 13:16:18 manuel1985: Yep, the XML file determines the layout used, including for the bootloader update payloads used for the Mender updates. Dec 16 13:21:52 * manuel1985 is frolocking Dec 16 13:34:09 Hi there, Dec 16 13:34:29 madisox: Okay, it seems we're fine. Size attributes remained unchanged throughout the file. Is the tegra flashing tool just putting every partition after the other? I noticed there is not offset attribute. Dec 16 13:35:21 Is it possible to change the override priority of conf/local.conf? I'd like it to be the last thing applied but the values entered there get overwritten by other layers. Dec 16 13:37:29 The use case is a development environment for board bring up. I want to be able to experiment in one place and split that into layers once something is working. Dec 16 13:38:02 Also I noticed that, in contrast to the zeus-made tegraflash.zip, in the dunfell-made tegraflash.tar.gz there is no flash.xml anymore. Only the flash.xml.in, which has the variables replaced by their actual values, though. Except for VERFILE, APPFILE and BPFDTB-FILE. Dec 16 13:40:45 BlueBus: This is were the local.conf gets included: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n759. As far as I know, all the conf files are taken into account as described in this file, then the resulting state is taken as base for every recipe, unmodified. That is, recipes don't affect each other. Dec 16 13:40:48 BlueBus: It really depends what you need to override. E.g. all _append actions are applied after all += actions. All _remove actions are applied last of all Dec 16 13:42:08 BlueBus: If you want to change the priority of the individual layers, that is, how they're stacked onto each other: yes, you can define that order somewhere. Dec 16 13:42:50 manuel1985 Thanks, I'm only reffering on the priority for local.conf Dec 16 13:44:46 * zeddii chugs a coffee Dec 16 13:47:14 paulbarker: Hm... Perhaps I could make something like work in conf/local.conf. `VARIABLE_remove=" * " VARIABLE_append=" the only value set in local.conf which will stay" Dec 16 13:47:50 The " * " is supposed to mean "remove all values regardless of what they were" :p Dec 16 13:47:55 BlueBus: _remove actions are applied last of all. You'd just end up with an empty variable Dec 16 13:48:23 Oh, allright :) Dec 16 13:48:34 _forcevariable is a horrible way to hack things but often useful in debugging Dec 16 13:48:51 Though I'm not sure on the exact ordering of how that is applied Dec 16 13:49:07 YMMV, check the `bitbake -e` output if you try it out Dec 16 13:49:42 Ouu, _forcevariable looks promising. Will take a look, thanks paulbarker Dec 16 13:53:47 Where is that _append _remove _whatever coming from? Is that Bitbake? Is there a comprehensive list which suffixes are there? Dec 16 13:54:22 Was wondering about that for a long time. Dec 16 13:54:56 Also, you seem to be able to set recipe-variables from the local.conf with PN__varname syntax. Did I get this right? Dec 16 13:54:57 manuel1985: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#appending-and-prepending-override-style-syntax Dec 16 14:00:30 LetoThe2nd: Thanks Dec 16 14:01:58 In my source tree, there are two functions: do_compile_tegra186() and do_compile_tegra194(). Do I just call do_compile and BitBake selects the right one based on some variable? Dec 16 14:02:11 I'm wondering if this is yet another BitBake variable naming feature Dec 16 14:03:16 https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Dec 16 14:03:40 kanavin_home: I think replacing varflags = d.getVarFlags(key, internalflags = True) with varflags = d.getVarFlags(key, internalflags = True, expand=["vardepvalue"]) in get_hash in data_smart fixes i Dec 16 14:03:42 it Dec 16 14:07:01 LetoThe2nd: Mind = blown Dec 16 14:07:43 "kabum" Dec 16 14:07:57 LetoThe2nd: GIVE THE SPHINX DOCS :D Dec 16 14:08:49 qschulz: meh.# Dec 16 14:09:03 qschulz: you're right, as always. Dec 16 14:12:41 I have to say though that the search feature is poor for now :/ Dec 16 14:33:40 is there any quick hack to make systemd-journald logs persistent in Yocto? I tried Storage=persistent in journald.conf, but there's still no logs from the previous boot... Dec 16 14:41:50 luneff: if you do figure it out it would be good to document it. I think there is meta/files/fs-perms-persistent-log.txt vs fs-perms.txt which may or may not help with systemd Dec 16 14:46:03 conf/bitbake.conf:VOLATILE_LOG_DIR ?= "yes" Dec 16 14:47:40 "To make the /var/log directory on the target persistent, use the VOLATILE_LOG_DIR variable by setting it to "no"." Dec 16 14:47:47 already documented, just hard to google Dec 16 14:51:27 You really need to be 100% sober to understand https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides. Dec 16 14:52:42 manuel1985: disagreed. Dec 16 14:59:49 manuel1985: always open to suggestions and patches :) Dec 16 15:08:52 I didn't mean to critize the text, it's just that the subject on hand is.. complicated. Dec 16 15:10:35 It is but we can always improve ;) Dec 16 15:19:34 RP: right, thanks for looking into it! This does look like outside of my competence area :) Dec 16 15:23:09 kanavin_home: I wasn't sure which way it would lead but I think its a bitbake bug :/ Dec 16 16:42:10 RP: I have what looks like a fix for the pseudo pyc file generation. It's a patch to pseudo itself to set the environment variable `PYTHONDONTWRITEBYTECODE` when executing a program under pseudo Dec 16 16:42:34 Should I sent the patch against pseudo? Or a patch against oe-core carrying the patch next to the recipe? Dec 16 16:42:45 paulbarker: isn't that 3.8 onwards only? Dec 16 16:43:43 RP: It's documented for 3.5: https://docs.python.org/3.5/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE Dec 16 16:44:11 https://docs.python.org/2.7/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE says "New in 2.6" Dec 16 16:45:04 paulbarker: hmm, ok, fair enough. I could have sworn I looked and the option we needed was 3.8 Dec 16 16:46:36 paulbarker: ok, lets add a patch to the pseudo repo and update. I can add a couple of other patches we have in OE to there too, clean things up Dec 16 16:46:37 It does the job. If I run python in do_compile and import test1.py I get a pyc file, if I do the same in do_install for a test2.py file I don't get a pyc file Dec 16 16:46:56 paulbarker: makes sense, I'm just wondering how I missed that :) Dec 16 16:47:00 No measurable difference in build time for core-image-sato Dec 16 16:47:17 paulbarker: good, I thought that would be the case but good to confirm Dec 16 16:48:27 Building on my machine from scratch (just downloads populated) was 63m27s before the change and 63m45s afterwards, probably just noise and other activity Dec 16 16:50:33 RP: I'll send a revert for the change in oe-core which added ${COREBASE}/meta to the ignored paths and send a separate patch against pseudo with the fix Dec 16 16:51:06 paulbarker: thanks. Dec 16 16:51:52 paulbarker: thinking about this, shouldn't we just export PYTHONDONTWRITEBYTECODE in FAKEROOTENV in bitbake.conf? Dec 16 16:52:48 RP: I didn't know that was possible. I added a `SETENV()` call within the pseudo C code Dec 16 16:53:07 Let me look, that would probably be a neater solution Dec 16 16:53:10 paulbarker: we export anything in that variable into the pseudo environment Dec 16 16:53:16 I now have a nice recipe I can use to quickly test Dec 16 16:53:38 Not sure if it's suitable for meta-selftest and a test case Dec 16 16:53:51 paulbarker: if we have one, yes, its suitable Dec 16 16:54:16 I'll see what I can throw together Dec 16 16:54:56 paulbarker: thanks, should be a nice simple fix in the end! Dec 16 16:55:16 paulbarker: I've just send out a patch merging a couple of other patches to the pseudo repo to clean things up Dec 16 16:55:33 particularly after my comments about reducing patch count the other day :) Dec 16 16:56:41 RP: I'll move my test recipe to meta-selftest and work up an oeqa test case Dec 16 16:56:55 paulbarker: thanks, sounds good Dec 16 16:56:59 Hopefully a patch will appear on the list later this evening or tomorrow Dec 16 17:00:52 rburton, kanavin_home: the retried builds worked so its something wrong with that worker Dec 16 17:01:10 halstead is looking into it (FWIW halstead, that machine seems to have broken when running builds) Dec 16 17:04:57 Line lengths in bitbake.conf make me cry Dec 16 17:18:37 RP: I thought that both ltp and ptest failing is difficult to explain otherwise, unless something introduced a qemu-on-arm-host regression Dec 16 17:23:18 kanavin_home: right, the build did complete so I presumed the worker was ok but obviously not Dec 16 19:00:53 i seem to vaguely recall that using IMAGE_ROOTFS is frowned on outside of do_rootfs(), is that the case? Dec 16 19:07:04 what's the best place to put my custom .dts file between recipes-kernel/linux/{,${PN}/,files/}custom.dts? Dec 16 19:09:44 v0n: Either '${PN}-${PV}', '${PN}' or 'files' directories next to your recipe will work. Which one you choose depends if you need to share the file between different recipes and/or versions Dec 16 19:11:35 paulbarker: I want the simplest version to add my own kernel dts in my BSP layer, no version distinctions at the moment Dec 16 19:12:51 zeddii: if an option in defconfig is set to 'm' and then I add a .cfg where I set it to 'y' it seems that tooling is picking up the one from defconfig which seems not right to me as cfg files should override the defaults isnt it so ? Dec 16 19:13:14 not if something else demands it be a 'm' Dec 16 19:13:17 v0n: All are equally valid. I'd use ${PN} though in case you add another recipe to the same directory later Dec 16 19:13:40 zeddii: http://sprunge.us/dgy2sM Dec 16 19:14:40 MTD_UBI(=m) has made it to m Dec 16 19:14:42 zeddii: there are just two providers Dec 16 19:14:45 the fragment cannot undo that. Dec 16 19:15:06 oic Dec 16 19:15:19 unless you put in the fragment, the change to mtd_ubi Dec 16 19:15:44 so tooling prefers modules it seems Dec 16 19:15:55 the tooling has no preference Dec 16 19:15:59 that's the kernel config subsystem Dec 16 19:16:02 if one of dependency is a module then it will pick module option Dec 16 19:16:14 yeah I meant kernel tooling Dec 16 19:16:19 gotcah Dec 16 19:16:31 gotcha even. yes. if a dependency is =m it chains down. Dec 16 19:16:55 which is why I enhanced the audit to show it more clearly. Dec 16 19:18:32 yes themessage is pretty neat thanks Dec 16 19:18:58 there is another issue I was seeing in odroid kernel too let me reproduce that Dec 16 19:23:52 paulbarker: ok thank you. Can I have a package agnostic recipe for any linux for does it have to be package specific like "linux-ti-staging_%.bbappend"? Dec 16 19:24:46 v0n: Not sure I totally understand your question, but I'll try anyway. "%" acts as a wildcard there Dec 16 19:25:18 wildcards should be used with care Dec 16 19:25:29 they can get you in trouble down the lane Dec 16 19:25:56 they bite you when you forget them Dec 16 19:26:02 khem is right. Have a think about what you want to achieve, should it be specific to the full recipe name, maybe even the version as well Dec 16 19:26:08 paulbarker: yes % acts as a wildcard for the version, but what if I want to use my dts for any linux (linux-ti-staging, linux-yocto, whichever kernel) Dec 16 19:27:11 v0n: % isn't specific to the version Dec 16 19:27:27 paulbarker: I have a bbb with a custom daughter board on it. I'm writting a bsp layer defining a new machine and I want to apply my custom dts on it. My machine is currently based on "beaglebone" from meta-ti which uses linux-ti-staging. Dec 16 19:28:11 linux-%.bbappend will match that but beware as khem says, using that you're effectively saying this append is compatible with any kernel recipe Dec 16 19:28:24 Consider that in future you may wish to support multiple MACHINEs, etc Dec 16 19:28:47 and also stepping on other peoples toes e.g. in a multi BSP env Dec 16 19:28:47 Sometimes better to be specific even if that leads to a little duplication Dec 16 19:30:20 paulbarker: can I specify my custom dts from the machine configuration or do I have to bbappend the kernel recipe? Dec 16 19:32:43 v0n: Either. I'd say machine config is a better option there Dec 16 19:33:03 zeddii: I am also seeing problem in CONFIG_LOCALVERSION setting in some cases Dec 16 19:33:21 v0n: We do this for the bbe. The bbe.conf file includes a kernel provider config like bbe-kernel-ti.inc: https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/conf/machine/include/bbe-kernel-ti.inc Dec 16 19:33:45 That config fragment sets the device trees to build Dec 16 19:34:02 Also https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/conf/machine/bbe.conf#L37 Dec 16 19:34:30 The BBE layer may be useful for you to review as it's essentially a modified BBB (more RAM, better wifi, etc) Dec 16 19:36:57 paulbarker: thank you, let me take a look at that! Dec 16 19:38:53 khem: eglibc is dead, right? Dec 16 19:40:23 RP: yes I attended the burial Dec 16 19:40:53 khem: I thought so. I'm just being asked some questions about it. Not sure why all of a sudden Dec 16 19:41:13 RP: yeah it was there in daisy timeframe Dec 16 19:41:51 RP: btw. you must have seen I am toggling a systemd patch based on 247 or 246 we need that patch with latest musl btw. reallocarray patch Dec 16 19:42:18 khem: I keep trying the 247 patches and they don't pass testing :( Dec 16 19:42:26 khem: let me add the 246 version to master-next Dec 16 19:42:37 yeah Dec 16 19:42:56 and ask 247 submitter to rebase on top of master-next Dec 16 19:43:45 zeddii: here is another kernel similar issue http://sprunge.us/qLOfLm Dec 16 19:43:56 khem: perhaps I should gamble you got it right and add it directly... Dec 16 19:44:28 RP: the patch is already in systemd/master so its ok Dec 16 19:45:05 I have been building with both 246/247 here with no issues, only problem is rebasing conflicts Dec 16 19:45:12 khem: is master breaks I'll be upset but its in :) Dec 16 19:45:32 worst case its a revert... Dec 16 19:46:13 ok let me check Dec 16 19:49:34 ok do_patch succeeded for systemd on master so I think we have it right :) Dec 16 19:50:21 Hmm, what MACHINE should I use for an Intel Atom x5 Z8350? Dec 16 19:50:35 More specifically, a Rock Pi X: https://wiki.radxa.com/RockpiX Dec 16 19:51:58 genericx86-64.conf if you use poky Dec 16 19:53:48 khem: Ah, simple enough. Thanks! Dec 16 19:56:13 thats one good thing about intel chips Dec 16 19:56:34 but dont open the hood :) Dec 16 20:20:57 JPEW: the other option would be meta-intel, it might have a specific tuning for those Atoms Dec 16 20:22:46 JPEW: we were using meta-intel's intel-corei7-64 machine in AGL, but there's not a lot of demand for x86 support from members so now just qemux86-64 is used with some kernel config additions Dec 16 20:39:24 @khem: What you see here http://sprunge.us/qLOfLm could be because LINUX_VERSION_EXTENSION and CONFIG_LOCALVERSION are unequal Dec 16 20:55:14 Well... that was easy Dec 16 20:55:27 tlwoerner: I have the Rock Pi X booting :) Dec 16 21:20:11 paulbarker: since I add custom u-boot and linux files for my beaglebone based board, should I use SRC_URI_append_ in their {u-boot,linux}-ti-staging_%.bbappend recipes? Dec 16 21:42:11 hum I'll keep them as SRC_URI_append because these recipes are supposed to be in the BSP layer so they couldn't be used without the defined layer machine(s) Dec 16 21:53:18 JPEW: sweet! B-) Dec 16 21:57:54 RobertBerger1: Dec 16 21:58:07 both are set to same value '-odroid' Dec 16 22:05:20 tlwoerner: Mind applying that patch for the rock-pi-4 serial port to meta-rockchip (it will need backport to dunfell as well)? Dec 16 22:06:01 JPEW: sure Dec 16 22:10:23 sorry, i though Bruce was going to apply it Dec 16 22:10:35 i'll go ahead and apply it now Dec 16 22:41:35 tlwoerner: Thanks! Dec 16 22:50:20 zeddii: RobertBerger1 in my case kernel recipe has LINUX_VERSION_EXTENSION ?= "-odroid" but defconfig has CONFIG_LOCALVERSION="" and after do_configme I get CONFIG_LOCALVERSION="-odroid" Dec 16 22:50:20 which is what i expect but then the question is why this warning from kernel tooling Dec 16 22:55:41 do I need MACHINEOVERRIDES =. "beaglebone:" ? Dec 16 22:56:42 I used 'require conf/machine/beaglebone.conf' to define my machine based on bbb, but images still go in a beaglebone/ directory instead of / Dec 16 23:15:54 meta-ti/conf/machine/beaglebone.conf in fact has only a few lines, should I require ti33x.inc instead of beaglebone.conf to define my own machine? Dec 16 23:28:16 yes you will need that MACHINEOVERRIDE to take advantage of all overrides that apply to bbb Dec 16 23:52:52 khem: hum nah MACHINEOVERRIDES seems to give existing machine(s) as alias(es) for the newly defined machine so that it benefits from existing VAR_append_ for example Dec 17 00:15:48 khem: indeed, run the build again and MACHINEOVERRIDES doesn't help in the creation of build/tmp/deploy/images/, still "beaglebone". Dec 17 01:11:58 JPEW: tlwoerner: which rock pi 4 to buy? 4b or 4c? Dec 17 01:12:15 JPEW: tlwoerner: add on boards? Dec 17 01:12:42 * moto-timo realizes shipping will now mean post sabbatical and that's ok...because #2020 Dec 17 01:14:03 khem: well requiring ti33x.inc directly doesn't create images// neither, I don't get it :-( Dec 17 01:17:43 why building for MACHINE= doesn't create a deploy directly with its name? Dec 17 01:18:01 ok show me your machine conf file Dec 17 01:19:13 'require conf/machine/beaglebone.conf' as the first line, then I += KERNEL_DEVICETREE, IMAGE_BOOT_FILES and IMAGE_FSTYPES. Dec 17 01:19:25 moto-timo: I think mine is a 4B Dec 17 01:20:26 Unfortunately, they have different device trees and meta-rockchip is set to 4B.... ideally we would include them all in the FIT image and let u-boot pick, but I don't know if there is any way for u-boot to know the model :/ Dec 17 01:20:55 * JPEW checks if u-boot knows the board model.... Dec 17 01:23:40 v0n: add MACHINEOVERRIDES .= ":beaglebone" as well in your machine conf Dec 17 01:27:20 moto-timo: u-boot does not appear to currently know the model. We may have to split the machines in meta-rockchip :/ Dec 17 01:34:35 moto-timo: rev C has one additional Mini DP port for dual display and the HDMI port connector is changed to Micro HDMI Dec 17 01:49:09 khem: still no / in deploy/images/ :-( Dec 17 01:56:05 khem: this is my conf/machine/foobar.conf: http://ix.io/2ImK Dec 17 02:12:51 Should I change DEPLOY_DIR_IMAGE myself? Dec 17 02:13:16 no, this looks ok. Dec 17 02:13:32 are you using MACHINE= Dec 17 02:16:09 khem: i'm using machine: in the kas file, which results in MACHINE ??= "" in build/conf/local.conf Dec 17 02:28:04 are you sure its respecting that ? what machine name do you see Dec 17 02:28:11 for MACHINE Dec 17 02:28:48 there's a bitbake command to grep that? Dec 17 02:39:11 bitbake -e |grep "^MACHINE=" Dec 17 02:45:41 khem: there's no "MACHINE" variable per-se Dec 17 02:45:58 there's MACHINE_ARCH="" **** ENDING LOGGING AT Thu Dec 17 02:59:57 2020