**** BEGIN LOGGING AT Wed Dec 02 02:59:57 2020 Dec 02 05:18:44 JPEW: yeah id vote for KubeEdge to get yoctoized also :) Dec 02 08:17:19 * snowing * \o/ Dec 02 08:19:43 glühwein! Dec 02 08:23:41 LetoThe2nd: too early :-D Dec 02 08:23:54 nope. Dec 02 08:24:00 LOL Dec 02 08:24:03 i miss fosdem. Dec 02 08:24:18 should really propose somthing for 2021 Dec 02 08:33:27 LetoThe2nd: too many online events, webinar, whatever and no time Dec 02 09:03:25 yup Dec 02 09:10:14 hi all Dec 02 09:10:41 how can one specify a git repo with dots in the name in SRCREV? Dec 02 09:10:52 in SRC_URI I mean, sorry Dec 02 09:11:09 bitbake seems to not like such repos Dec 02 09:11:23 this one for example https://github.com/gordboy/rtl8812au-5.9.3.2 Dec 02 09:12:50 norcot: isn't that effectively a version number? Dec 02 09:13:25 LetoThe2nd, it is the kernel version that driver is for, yes Dec 02 09:14:21 i would probably name the recipe rtl8812au_5.9.3.2.bb then and use ${PV} to inject it. Dec 02 09:14:51 Hi All,Has anyone something to suggest about https://lists.yoctoproject.org/g/yocto/message/51593, please?Thanks! Dec 02 09:15:25 https://lists.yoctoproject.org/g/yocto/message/51593 Dec 02 09:16:54 LetoThe2nd, I renamed the recipe to rtl8812au_5.9.3.2.bb and in SRC_URI I changed it now to git://github.com/gordboy/rtl8812au-${PV}.git;protocol=https but still the same problem Dec 02 09:17:24 norcot: what are the concrete problematic effects, then? Dec 02 09:17:40 RROR: rtl8812au-5.9.3.2-r0 do_fetch: Fetcher failure for URL: 'git://github.com/gordboy/rtl8812au-5.9.3.2.git;protocol=https'. Please set a valid SRCREV for url ['SRCREV_default_pn-rtl8812au', 'SRCREV_default', 'SRCREV_pn-rtl8812au', 'SRCREV'] (possible key names are git://github.com/gordboy/rtl8812au-5.9.3.2.git;protocol=https, or use a ;rev=X URL parameter) Dec 02 09:19:51 in the logs I get: DEBUG: For url git://github.com/gordboy/rtl8812au-5.9.3.2.git;protocol=https returning http://downloads.yoctoproject.org/mirror/sources/git2_github.com.gordboy.rtl8812au-5.9.3.2.git.tar.gz Dec 02 09:20:01 norcot: so, and do you have a SRCREV set? Dec 02 09:21:20 yes, I've set it to RCREV = "b29ed41df1c3e47f646dc06e0308ae6f06ae18ac" Dec 02 09:21:23 LetoThe2nd, ^ Dec 02 09:21:30 SRCREV = "b29ed41df1c3e47f646dc06e0308ae6f06ae18ac" Dec 02 09:22:14 and Dec 02 09:22:15 SRC_URI = "git://github.com/gordboy/rtl8812au-${PV}.git;protocol=https" Dec 02 09:23:16 damn Dec 02 09:23:27 needed to specify branch name to "main" Dec 02 09:23:30 :) Dec 02 09:23:36 sorry for the trouble Dec 02 09:23:42 norcot: i see. then its probably really time to either start digging the verbose logs and/or the git fetcher, unless there is some other side effect that you haven't noticed/mentioned. technically i don't thing the dots should make a difference, but thats not an authorative information. Dec 02 09:23:45 ah.. :) Dec 02 09:24:06 hooray for projects moving away from branch mastery. Dec 02 09:26:06 yeah, didn't pay attention to the repo too much Dec 02 09:26:17 thanks for the time LetoThe2nd Dec 02 09:26:29 np, have fun. Dec 02 09:31:23 thanks, you too Dec 02 13:00:57 alessioigor: maybe denix can help you ^ Dec 02 13:07:48 mckoan: meta-ti was the first place where I started to looking for help ;-) Thanks anyway Marco! Dec 02 13:47:17 Hello, I wonder if there is a best practice how to handle device tree files? ATM I have a recipes-kernel/linux folder within my layer and there is a patch which does add the dtb to the kernel dts Makefile and which does also create the dts file in the /arch/arm/boot/dts/ folder. During development this is a little bit unhandy. I would think about something like the pure dts file in my recipes folder which gets copied over to th Dec 02 13:47:17 e arch folder and gets built. Are there any best practice guidelines on such tasks? Thanks, F Dec 02 13:50:35 FloRiAn_I don't know best practice but I do it in this way: Dec 02 13:50:41 https://github.com/voltumna-linux/tmu/blob/master/recipes-kernel/linux/tmu-dts_git.bb Dec 02 14:05:51 alessioigor Thanks for your response. Is the "inherit devicetree" in your recipe enough, to let this recipe build the dtb from the dts out of the given git repo? atm I don't get it, why the dts is compiled. Dec 02 14:06:52 I compare it to http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb?h=master atm Dec 02 14:08:26 FloRiAn_ Perhaps their is better! Dec 02 14:10:11 Anyway "all roads lead to Rome" ;-) It was very helpful that you pointed me to your code! Thanks a lot! Dec 02 14:17:26 RP: Ok, I looked at the hash equiv socket path code. The server correctly does a chdir to ensure the path is not too long; the client does not (and the e-mail was about the client, not the server) Dec 02 14:21:13 RP: hi, I'm looking at setting up a CI system for a yocto based system; are there any well-known practices for a workflow involving multiple repositories that I could look at Dec 02 14:23:03 I'm not that familiar with yocto or how it is usually developed Dec 02 14:24:14 zyga: multiple repositories as in? Dec 02 14:25:16 LetoThe2nd as in distinct libraries or other components separately developed in their own repositories that all together participate in a bigger build through bitbake + set of layers Dec 02 14:25:41 currently, perhaps unlike what yocto does, this arrangement also uses git-repo and manifest files Dec 02 14:26:07 but I was curious if it is practiced elsewhere in general, regardless of how the tree is assembled (repo vs other systems) Dec 02 14:26:45 zyga: well i think you're already half-answering your question yourself. all the libraries/components live in their own respective repositories, and there's layers that contain recipes that pull those components in. Dec 02 14:27:34 sure but are there any well-known examples of CI loops around that Dec 02 14:27:36 zyga: the only real variations that matter is how the build setup is actually assembled, e.g. repo vs. kas vs. git submodules vs. combine-layers vs. homebrew Dec 02 14:28:10 my current thinking is that commit or pull request in any leaf needs to re-assemble a set of "reference" configurations and build it Dec 02 14:28:28 hmm. Dec 02 14:28:37 not sure. but i've also not heard of such. Dec 02 14:28:48 but there's some, probably, boring glue logic required, setting up the right tree, switching some parts to represent the change (pull request rev) vs what's in the reference manifest, etc Dec 02 14:29:24 most cases i know only trigger on the main defition file that glues everything together. but i'm also sure that this is not the whole truth. Dec 02 14:29:33 I'll be setting up something like this for open harmony, I'll gladly share my ideas and code Dec 02 14:30:01 my current draft architecture has gitlab pipelines on the main repo and triggers from leaf repos Dec 02 14:30:29 maybe https://pretalx.com/yocto-project-summit-2020/talk/ZPFZJU/ Dec 02 14:31:04 but since i only have one repo for now, it's rather theoretical at the moment Dec 02 14:31:12 oh, nice, thanks Dec 02 14:31:56 I'll go and study that, thank you Dec 02 14:34:59 for the sake of completeness here comes the presentation https://www.youtube.com/watch?v=luxMUcOB_JM&list=PLD4M5FoHz-TwZkOR-GoWjq5XlLpZIFt5-&index=7 Dec 02 14:35:36 thanks! Dec 02 14:35:51 I'm also building a CI/CD pipeline at the moment. Dec 02 14:36:49 oh, nice Dec 02 14:37:12 do you plan to reuse tekton? Dec 02 14:37:15 I didn't know about it so I picked gitlab pipelines as a starting point Dec 02 14:37:32 but it's so early I can still change pretty much everything Dec 02 14:38:40 As preparatory work I strongly recommend to setup kas for your project (as I did the last couple of days - thanks LetoThe2nd for the hint btw!). Kas comes in a docker container. Nice benefit is that I can plug that docker container right into my drone-ci pipeline, build my kas projectt. And then hopefully deploy them with mender on my dev boards (I'm not quite there, yet but that would be my personal strategy). Dec 02 14:39:20 sounds nice Dec 02 14:39:29 I think our environment settled on git repo for now Dec 02 14:39:48 mainly for "comfort" compatibility with the non-yocto copy of open harmony Dec 02 14:40:36 I guess it's a legit alternative, even though I haven't used that except for cloning some test projects. Dec 02 14:40:48 emrius as for board deployment, did you pick mender for a specific reason? Dec 02 14:41:01 I'm personally very, ahem, familiar with lava Dec 02 14:41:06 and with ubuntu-core Dec 02 14:41:15 but for open harmony I wanted to go a different route Dec 02 14:41:19 ... I liked their webpage and didn't have any experience :) Dec 02 14:41:23 (only for CI, not for anything production related) Dec 02 14:41:58 heard that lava comes with a steep learning curve (as everything in this field I guess...). Dec 02 14:42:06 the main pain point of repo is that you either need cusom script magic to setup local.conf, or ship some more-or-less matching template files along. other than its certainly an option, but i personally think its strenghts are not exactly matching the usual yocto development requirements. Dec 02 14:42:10 hello, I am trying to use INCOMPATIBLE_LICENSE="GPLv3" to exclude GPL3 licenced stuff from my images. however I have a build-time dependency (DEPENDS) on a package which does not involve any object linkage, so I know it is safe. how can I permit that gplv3 package while still protecting myself from accidentally installing *any* gplv3 package in my image? Dec 02 14:42:20 for open harmony I'll be separating the remote installation of the built image into a separate component, as there will be several distinct consumers Dec 02 14:42:56 to clarify: the DEPENDS includes a gplv3 package, but I do not link against it, nor do I include it in the image, but I am not able to build if I simply put GPLv3 in INCOMPATIBLE_LICENSE Dec 02 14:43:04 bps: hum, whiteliesten the license for that specific -native package? Dec 02 14:43:19 LetoThe2nd as for repo, i don't have strong feelings for any of those tools; I perhaps dislike repo because it phones home but I will just patch that away Dec 02 14:43:36 but that part is out of my hands Dec 02 14:44:10 bps: you can enable build of some GPLv3 recipes, e.g. tooling but mask their binary packages out from images. E.g. in distro config: WHITELIST_GPL-3.0 += "binutils" and PACKAGE_EXCLUDE += "binutils-dbg binutils-staticdev binutils-dev binutils-doc binutils-locale libbfd binutils" Dec 02 14:44:20 Hello everyone, I want to create a variable and load it into the datastore. The example in the bitbake docs shows something like this - export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR". However, I will love to specify the default value of the variable but not sure about how to do it. Dec 02 14:44:32 LetoThe2nd, so if it's DEPENDS="python3-rfc3987", you suggest to put WHITELIST_GPL-3.0="python3-rfc3987-native" ? Dec 02 14:44:56 emrius I know lava very well, I think the main learning curve part there is that it requires working board automation Dec 02 14:45:06 so that you can spin up physical devices on demand Dec 02 14:45:20 sounds tempting! Dec 02 14:45:47 then most of the bits are not so hard, it's just a bit orthogonal as it comes with it's own set of features for testing that are extras if you just need programming and passing control to something else Dec 02 14:45:54 bps: if its the native incarnation that is being built, yes. Dec 02 14:46:19 bps: for more advanced case, no idea, sorry. Dec 02 14:46:28 I think the problem is that it wants to build it for the target toolchain, so it still tries to build the non-native version Dec 02 14:47:11 mcfrisk, I tried to use PACKAGE_EXCLUDE_pn-my-cool-image = "gplv3-package" but I haven't figured out yet if that will work Dec 02 14:47:53 zyga: I guess I'm a pretty lazy webpage reader and got a little intimidated by the lava landing page... Dec 02 14:48:02 Might give it a shot soon Dec 02 14:48:39 emrius it has some nice features that can be valuable if you want to do long term testing and track results Dec 02 14:48:54 bps: one more example from my distro config: INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+", WHITELIST_GPL-3.0 += "gdb", PACKAGE_EXCLUDE += "gdbserver gdb-dbg gdb-staticdev gdb-dev gdb-doc gdb-locale gdb" Dec 02 14:49:04 my current setup involves flashing over serial/usb and muxpi for booting with SD cards Dec 02 14:49:35 mcfrisk, yes, I already had trouble with gdb. thanks for the example. will this still enable me to install gdb in my SDK though? Dec 02 14:50:04 looks similar on my end Dec 02 14:50:26 emrius are you using muxpi by any chance? Dec 02 14:50:40 unfortunately not Dec 02 14:50:52 I want to package the muxpi ecosystem, mainly the firmware side, for Debian so that it can be maintained there Dec 02 14:50:58 right now setting up a new board is rather manua Dec 02 14:51:00 *manual Dec 02 14:51:42 emrius are you familiar with that board though, I don't know of many other systems for boot testing devices that only do SD cards Dec 02 14:53:30 No, sorry! I've used orangepis and raspberrypis using SD flashed OSs Dec 02 14:54:47 emrius flashed by hand? Dec 02 15:04:37 bps: I think so, though I might have some other magic for SDK. but it allows to build gdb but makes sure none of the packages are allowed on images by default, but can be installed from package repo. Dec 02 15:05:00 zyga: Samsung have a developed a system for that, lemme skim through the talks Dec 02 15:05:01 mcfrisk, thanks a lot for your help, I think it's exactly what I need! Dec 02 15:05:12 qschulz yes, slav Dec 02 15:05:16 I'm familiar with it Dec 02 15:05:24 (small world in some way) Dec 02 15:05:38 qschulz muxpi is a part of that stack Dec 02 15:06:11 ubuntu-core is using muxpi for testing already and, I believe, they hired the board designer a few years back Dec 02 15:10:21 I got lost reading only half of the messages so I'll stop here :) Dec 02 15:10:33 +by reading Dec 02 15:10:43 :-) Dec 02 15:29:07 JPEW: ah, right, yes, on the client side. I think I was getting confused in the meeting yesterday Dec 02 15:38:04 RP: I have a patch to fix it for the synchronus client; I'll send it in a bit Dec 02 15:38:22 JPEW: cool, thanks! Dec 02 16:07:53 can INCOMPATIBLE_LICENSE be put in image recipe ? Dec 02 16:08:01 will it be read / respected there Dec 02 16:09:59 Ad0: nope. Dec 02 16:10:06 Ad0: yocto chant #1 applies. Dec 02 16:10:52 hah what is that Dec 02 16:11:56 Ad0: https://www.instagram.com/p/CBgEgS_jXTD Dec 02 16:12:14 rofl nice Dec 02 16:12:18 I will put it in the distro base files Dec 02 16:12:59 I need to find an alternative to bash I guess Dec 02 16:13:45 Ad0: busybox has some Dec 02 16:13:51 dash and ash IIRC Dec 02 16:15:38 alrite Dec 02 16:15:42 or bash from meta-gplv2 if you like outdated stuff Dec 02 16:15:46 http://layers.openembedded.org/layerindex/recipe/60563/ Dec 02 16:15:50 hehe Dec 02 16:16:06 well should all my bash scripts just be /bin/sh at the top to not be tied to a specific bash Dec 02 16:19:39 if you don't have bashism in them, thats well Dec 02 16:19:43 damn bluez requires readline Dec 02 16:22:34 readline is gpl3 Dec 02 16:30:28 Ad0: its optional, turn it off Dec 02 16:31:01 bonus points for sending a patch automatically disabling it if GPLv3 is in incompatible licenses Dec 02 16:33:07 zyga: sorry for the late reply. Yes flashed by hand. Or flashed remotely using mender Dec 02 16:35:36 rburton: bonus beer points or bonus brownie points? Dec 02 16:39:59 brownie, obviously Dec 02 16:40:33 I have a stash of genuine beer tokens that i'm not going to use but they're of limited value outside of a 20 mile radius of here Dec 02 16:43:42 YP website down? Dec 02 16:45:47 jonmason: works here Dec 02 16:45:59 weird, I've tried it multiple times now Dec 02 16:47:08 RP: world repro is not quite finished yet, after adding to exception list everything that non-reproduces reliably, a few more failures popped up that are sporadic Dec 02 16:47:09 and it works on my work laptop via vpn....something is hosed somewhere Dec 02 16:47:17 but I am getting there Dec 02 16:48:00 RP: and adding the links to sporadic failures so that anyone can have a starting point: Dec 02 16:48:00 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/world-repro&id=f020c3cdd0af490913169f2738d46ce9f1cedde4 Dec 02 16:48:04 kanavin_home: no problem, I know how annoying some of the issues can be to track down Dec 02 16:48:24 kanavin_home: feel free to send work so far if that helps Dec 02 16:48:49 RP: yes, typically it's something like os.walk() which returns files in different order depending on whatever Dec 02 16:48:56 kanavin_home: its great even to get down to that list! Dec 02 16:49:08 kanavin_home: yes, those are a pain. I've chased those in bitbake's parsing too Dec 02 16:49:42 kanavin_home: I've been watching the branch and quietly cheering you on! :) Dec 02 16:50:25 RP: yeah, frankly I would add items like piglit to exception list, but I have already made four custom patches to it, and that makes me press on with it :D Dec 02 16:53:17 I'm upgrading my custom kernel from 4.14 to 5.4.47 on thud. For some reasons, it cannot build when icecc is enabled (race apaprently for CONFIG_IKCONFIG) Dec 02 16:53:23 Might be a long shot, but anyone got an idea? Dec 02 16:54:34 (compiling on thud) Dec 02 16:56:11 | {standard input}: Assembler messages: Dec 02 16:56:13 | {standard input}:10: Error: file not found: kernel/config_data.gz Dec 02 16:56:15 | ICECC[12969] 16:10:18: Compiled on 10.1.14.121 Dec 02 16:56:17 | /tmp/StreamSDK-build-yocto/work-shared/stream1955music/kernel-source/scripts/Makefile.build:265: recipe for target 'kernel/configs.o' failed Dec 02 16:56:32 qschulz: Ah, that Dec 02 16:56:56 The file doesn't exist on the remote compilation node Dec 02 16:57:14 Because it's a binary being embedded into an assembly file Dec 02 16:58:12 JPEW: very not aware of what icecc is doing behind the scenes so not sure to understand the bug/limitation? Dec 02 16:58:45 it's sending the pre-processed source code to be be compiled on remote nodes Dec 02 16:58:48 also, is there something I can do about this except disabling icecc for it? Dec 02 16:59:02 Not really :/ Dec 02 16:59:24 quite frustrating for a kernel Dec 02 16:59:31 qschulz: Ya Dec 02 16:59:33 one of the biggest piece of SW built on our Yocto :/ Dec 02 16:59:45 It's possible they've improved it in newer versions of icecc Dec 02 17:00:01 depends where this is handled Dec 02 17:00:17 qschulz: Almost all of the "important" logic in icecc is client side Dec 02 17:00:21 because well... using old stuff for our product is not enough, we also dev on old distros... Dec 02 17:00:26 (some of us at least) Dec 02 17:00:39 so an icecc upgrade... Dec 02 17:00:44 At least, all the quirks are handled client side Dec 02 17:00:55 Ya; do you build in a container? Dec 02 17:01:29 of course not :) Dec 02 17:01:59 and probably not an option either, at least short term, so we'll anyway have black sheeps in our icecc "pod" Dec 02 17:02:15 pod? Dec 02 17:02:56 well, don't know how you call a network of machines connected through icecc Dec 02 17:03:08 like, we have one scheduler and all our machines are available to the scheduler Dec 02 17:03:09 qschulz: ah. "cluster" usually Dec 02 17:03:15 yes, thank you Dec 02 17:04:46 well... I guess that's how I end a day of work. /me sad Dec 02 17:04:55 JPEW: thx, have a nice evening Dec 02 17:05:14 (also, why didn't this fail in 4.14?) Dec 02 17:05:42 qschulz: They changed how the config is embedded Dec 02 17:07:15 and I guess we're not using icecc on the autobuilder right? Dec 02 17:07:44 qschulz: Depends Dec 02 18:35:42 JPEW; that is cool about KubeEdge... and I think I agree with OutBackDingo it needs to be yoctoized ;) Dec 02 23:06:37 df -h Dec 02 23:07:47 out of space Dec 03 00:23:44 armpit: there are few dunfell meta-oe patches on github Dec 03 00:24:04 armpit: also some zeus patches on patchwork I Wonder what plan is for them Dec 03 00:25:11 khem, I noticed.. Ill look at them tonight Dec 03 00:25:23 ok Dec 03 02:28:45 woot. finally got my dumpster fire shirt. @jonmason thanks! Dec 03 02:56:25 zeddii: awesome! Glad to see international ones are arriving. I got mine about a week or two ago. Dec 03 02:57:03 Now to wait an appropriate amount of time and do OE coffee mugs ;) **** ENDING LOGGING AT Thu Dec 03 02:59:57 2020