**** BEGIN LOGGING AT Fri Nov 20 02:59:57 2020 Nov 20 03:18:35 oh ..btw this is an LXC containerized distro Nov 20 03:36:37 zeddii: why is it crash looping, post the logd Nov 20 03:36:51 ~logs~ Nov 20 07:33:41 hi qschulz, i just learned by accident.. that you don't need the bitbake: in cross references with intersphinx.. you can use it to disambiguate (if needed), but it works otherwise.. Nov 20 07:36:45 well, in fact, we have a few occurences already where it's missing! Nov 20 07:43:46 @JPEW: very interesting stuff - please keep me posted as well. Nov 20 07:44:01 @JPEW - tekton/CI Nov 20 07:44:39 yo dudX Nov 20 07:44:54 and yo q-i-told-you-so-schulz ;-) Nov 20 07:44:59 good morning Nov 20 07:45:23 Hi everybody! Nov 20 07:47:08 hm. do i now wrangle js/ts testing, prepare livecoding demos, or finde me coffee/beer? Nov 20 07:52:04 @LetoThe2nd start with beer, then coffee and afterwards the thing with the curse words Nov 20 07:53:34 RobertBerger: good plan. concerning livecodign demos, i yesterday found that one of those actually went into the arctic vault, which is highly amusing: https://github.com/LetoThe2nd/libanswer Nov 20 08:22:26 'morning, all.. Nov 20 08:31:31 I just discovered the yocto jester picture.. nice and funny :) Nov 20 08:32:17 \o/ Nov 20 08:33:12 just misses the sleighs bells at the tip of the hat branches xD Nov 20 08:33:26 for v2, perhaps :) Nov 20 08:48:13 I'm getting a QA issue, this morning, related to symlinks.. I indeed noticed that deleting symlinks would not raise QA issue but I can't see the point over here.. any insight ? https://paste.ubuntu.com/p/S4tPsmnKzt/ thks Nov 20 09:37:49 ndec: oh! not great. It's going to be a game of whack-a-mole to find all the missing bitbake: :/ Nov 20 09:38:56 LetoThe2nd: I hope your enjoyed receiving 32 times the same mail :) Nov 20 09:39:18 well, it works without it.. so it's not a big deal.. Nov 20 09:39:43 for refs it's easy to find them. for terms much less. Nov 20 09:40:48 and if a term exists in both yp-docs and bitbake-docs, then yes, it might be problematic Nov 20 09:40:52 qschulz: yes, i celebrated it! Nov 20 09:44:13 ndec: can terms be prefixed with bitbake: too? Nov 20 09:44:22 yes. Nov 20 09:45:03 git grep ":term:\`bitbake:", there are a few alrady Nov 20 09:45:56 and git grep "bitbake-user-manual/" | grep -v "bitbake:" gives the places where we missed bitbake: Nov 20 09:53:14 ndec: ok, so it's not going to be a nightmare to fix :) Nov 20 10:03:37 Hi! I am building image containing icedtea7-native which does not compile due to some -Werror related error. I would like to remove -Werror flag Nov 20 10:03:39 http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/icedtea/icedtea7-native.inc?h=master Nov 20 10:04:26 I tried CFLAGS_remove = "-Werror" and CXXFLAGS_remove = "-Werror" - it doe not work. Nov 20 10:05:08 Also there are already -Wno-error=stringop-overflow -Wno-error=return-type, the same error types as I have Nov 20 10:05:45 DanmerZ: try altering TARGET_CXXFLAGS Nov 20 10:06:30 and bitbake -e to see the content of your variable.. Nov 20 10:09:07 use magic with bitbake -e! https://theyoctojester.info/session_14/main.html Nov 20 10:11:41 @DanmerZ: which verson of meta-java do you use? Nov 20 10:12:11 @DanmerZ: can you dump the error log somewhere, like pastebin? Nov 20 10:12:31 @DanmerZ: Do you use master? Nov 20 10:13:14 @DanmerZ: what's the version of the "host" gcc of your build machine? Nov 20 10:14:11 gcc version 9.3.0 Nov 20 10:14:50 meta-java: commit 3b65eea96eddde97169ca5e00be01a9dbd257786 from Thu Aug 20 Nov 20 10:15:54 https://pastebin.com/8AuRy8pK Nov 20 10:19:05 @DanmerZ: So I guess you try to get rid of this compiler flag ? -Werror=return-type Nov 20 10:19:13 yes Nov 20 10:19:35 CFLAGS_append = " -Wno-error=stringop-overflow Nov 20 10:19:44 CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type" Nov 20 10:20:11 but I see in compile log both -Werror and -Wno-error=return-type Nov 20 10:20:49 @DanmerZ: Can you try something like that? http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/icedtea/icedtea7-native.inc#n34 Nov 20 10:22:32 @DanmerZ: I see this as well: http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/icedtea/icedtea7-native.inc#n29 Nov 20 10:22:35 hmm strange ;) Nov 20 10:32:42 the strange thing that the same icedtea7-native version 2.1.3 compiles in other image for different platform Nov 20 10:48:45 CFLAGS_append = " -Wno-error" helped Nov 20 11:48:14 Hi, where I should send patches for the layer named "meta" of yocto? I am porting some patches so it can work when the host uses GCC-10. I know that there are a mailing list for meta-yocto and meta-yocto-bsp and another for OE layers. But I have doubts about the "meta" layer Nov 20 11:49:18 stkw0: meta == oe-core. so, the oe-core mailing list probably. Nov 20 11:49:22 stkw0: hi, the meta layer in poky is openembedded-core Nov 20 11:49:37 Okay, thank you very much. Nov 20 11:50:23 stkw0: have fun! Nov 20 11:52:12 stkw0: which release of Yocto are you on? Nov 20 11:52:54 qschulz: the bestest one, of course! Nov 20 11:54:12 qschulz: zeus, with gatesgarth those bugs seems to be fixed, but for now we rely on zeus (we are planning to upgrade to official supported release though), but it will be nice if those patches are backported to zeus Nov 20 11:55:12 stkw0: If I'm not mistaken zeus is at best community supported, at worst EOL. Nov 20 11:55:14 * LetoThe2nd isn't sure somebody will take patches for zeus still Nov 20 11:55:28 according to release page it's community support. Nov 20 11:56:00 I guess small patches to current packages can be accepted¿? Nov 20 11:56:01 stkw0: I'd suggest moving to dunfell maybe? *it's the lts that will be supported for at least 2 years (probably more if there's financial support) Nov 20 11:56:30 stkw0: well, if anyone actually maintains it, sure :) no version bumps but patches welcome Nov 20 11:56:44 qschulz: The problem is that meta-xilinx don't supports dunfell (and don't want to do it, I read they want to go directly to Gatesgarth) Nov 20 11:56:52 didn't know dunfell was a lts.. Nov 20 11:57:27 stwcx: nobody stepped up to continue zeus' maintenance Nov 20 11:57:50 sorry, stkw0: ^^^ Nov 20 11:58:36 RP: so basically, althought zeus in theory is "Community support" in practice it is EOL?? Nov 20 12:00:47 stkw0: effectively nobody has stepped up so yes, we should probably just mark it EOL. The focus around the LTS has meant the other branches have withered since people are aiming for LTS Nov 20 12:01:14 PaowZ: its not like it was a secret... rather the exact opposite. Nov 20 12:01:22 jaja, okay Nov 20 12:03:07 It is cool to have an LTS release, I think it's the first LTS release of yocto?? I would like other layers like meta-xilinx also gave LTS support. We are a small team and sometimes it's hard to keep up with yocto releases... Anyway, thank you very much for your information Nov 20 12:04:30 stkw0: it is the first LTS release, we're still figuring some of the details out :) Nov 20 12:05:02 RP: some == 3. the L, the T, and the S ;-) Nov 20 12:05:49 releasing was clear. Nov 20 12:06:02 LetoThe2nd: surely.. it sounds that I hadn't read it somewhere.. but now you said so.. https://wiki.yoctoproject.org/wiki/Releases Nov 20 12:08:13 PaowZ: i've done a specific QS session on it, it was a prominent keynote at ELC, and also ELC-Almost-EU... so its actually quite an accomplishment to have missed it. maybe get in touch with ndec so he can improve his marketing skillz to reach folks like you in the future too :-) Nov 20 12:09:48 no kidding, thats really what i have done a couple of times already. when people told me "i've missed your session every time", i was like: please tell me where you get your information from, so i can improve my announcements. Nov 20 12:10:41 LetoThe2nd: PaowZ : right i am interested in how we can improve that for sure! Nov 20 12:11:29 ndec: for me the result was that the upcoming session is the first one to have been announced on instagram and youtube :) Nov 20 12:12:20 instagram... ;) Nov 20 12:12:52 ndec: i loathe producing content for instagram. the process is just like super ugly. but if it helps... Nov 20 12:13:23 i think i will soon request for help on the social media things.. i am not scaling ;) Nov 20 12:13:39 https://www.instagram.com/p/CHpa_tSpBjP/?utm_source=ig_web_copy_link Nov 20 12:13:48 for example, i've never paid attention to the yp facebook, i might need someone to volonteer with that. Nov 20 12:14:10 facebook is probably my last blind spot these days. Nov 20 12:14:12 LetoThe2nd: where you learn that instagram likes squares ;) Nov 20 12:15:19 as i said.. ugly process. Nov 20 12:15:32 i'll have to do distinct formats for YT and instagram next time. Nov 20 12:17:46 ndec: Have you seen the things I've posted to youtube? Nov 20 12:20:58 paulbarker: yes, well, briefly, but I am aware~ Nov 20 12:21:03 aware! Nov 20 12:21:50 i had noted down to talk to you about it.. see how we could promote them. Nov 20 12:27:17 paulbarker: can you give me a short headsup during the next session on tuesday so i remember promoting it too? Nov 20 12:27:33 LetoThe2nd: I'll try to remember Nov 20 13:35:50 Hi everyone, I am trying to use some bitbake variables in a custom task (e.g. DATETIME) within a image/recipe which triggers the error message"When reparsing meta-foo/.../example.bb the basehash value changed from 7c3cf034aa66cd3aa59eb499c150d43f to 82f30bcb522d708d95716b904dd61d8f. The metadata is not deterministic and this needs to be fixed." Nov 20 13:35:57 example.bb:do_task_foo () { mkdir /tmp/${DATETIME})addtask task_fooI assume this is due to the DATETIME variable changing during the reparsing, but I am not quite sure how to deal with this? There surely must be a way to use the bitbake variables in tasks in a meaningful matter? Nov 20 13:39:21 by not using DATETIME :) Nov 20 13:46:07 well, the thing is that I want to do stuff with artifacts from other tasks within the current build task, say bundle multiple images into a release structure. and since the artifacts are named using the DATETIME variable (e.g. https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#var-IMAGE_NAME) I though this might be a sensible way to Nov 20 13:46:07 access these Nov 20 13:56:45 Ben48: then please use the proper means for that. bundling multistage builds shall be done through multiconfig chaining, not through trickery which is bound to break sooner or later. Nov 20 14:07:14 LetoThe2nd: that might be quite an accomplishment, indeed, but I have to admit it's hard to follow tons of posts from every discussions/twitter/twitch/fb threads.. Nov 20 14:07:36 but now, I know :) Nov 20 14:11:24 :) Nov 20 14:12:23 LetoThe2nd: I must admit, that I am not quite sure how multiconfig might help with my dilemma. Maybe you could elaborate a bit more. But first I suppose I should make my intentions a bit clearer for you. Nov 20 14:16:03 Ben48: well you said 1) i build artifacts 2) a secondary build needs to bundle in those artifacts. this is exactly what multiconfig is there for. Nov 20 14:24:20 LetoThe2nd: so the way we currently do a firmware release is by building the target images first and then a shell script which essentially moves all the build artifacts together, adds some meta-information (some from extern, some from "within" yocto) and tars the whole thing as release. Now, I am not happy with this current solution, as the bash Nov 20 14:24:21 script is bound to make assumptions about the build (e.g. machine name, rootfs imagetype etc.) and thus does not handle changes well and relies heavily on regex magic which is bound to fail at some point. so my idea was to move this whole "release" work into the yocto build process itself, as yocto would provide most of this needed information Nov 20 14:24:21 within environment variables. So now I am trying to run a task doing exactly this after all three images (and sdk population) built successfully. Nov 20 14:25:35 LetoThe2nd: P.S.: I am relatively new to the yocto project so please do not tear my head of for not knowing the mega-manual from heart ;D (btw. great videos, they helped me alot '=D ) Nov 20 14:25:58 Ben48: multiconfig. it really is what you want. Nov 20 14:26:10 And glad you like them. Nov 20 14:26:28 * LetoThe2nd is off into the weekend though Nov 20 14:27:31 LetoThe2nd: ok, multiconfig it is then ;) Nov 20 14:29:19 * LetoThe2nd really shall do a mc session soon. Maybe for Christmas. Nov 20 14:42:35 +1 for multiconfig for this specific usecase Nov 20 14:46:55 Is there any way to make an image so that when I build for my target I can also run the image on qemuarm? Nov 20 14:47:15 (assuming my target platform is an arm of course) Nov 20 14:49:54 multiconfig ;) https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#dev-building-images-for-multiple-targets-using-multiple-configurations Nov 20 14:59:28 But then the thing I run on the qemu would not be the same image as the one i run on the target, would it? Nov 20 15:03:44 No, it wouldn't. You would build two separate images, one for target, one for qemu. I'm not sure how feasible it is to get the target image to run within qemu, as the machine config would differ. What stops you from just building two images? Nov 20 15:05:25 PaulFraOSAA: if qemu can run your target, then you can trivially tell qemu how to run it Nov 20 15:05:46 ok, how? Nov 20 15:05:59 all the QB_* variables that the qemu machines set Nov 20 15:06:19 Ah, thank you. I'll look into that :) Nov 20 15:06:28 for proof that it isn't specific to the qemu machines, http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/conf/machine/include/qemuboot-intel.inc Nov 20 15:06:55 you might need to build a second filesystem that qemu can boot directly, depends on what you;'re building already Nov 20 15:11:30 Great, that was excactly what I was looking for. I thought I'd seen it, but I couldn't find the documentation for it anywhere. Nov 20 15:11:58 the docs for qemuboot.bbclass, i imagine Nov 20 15:30:32 Well thank you, gave a good weekend Nov 20 15:36:36 RP: one of the numpy ptest expects you to have 2G RAM :) Nov 20 15:37:11 otherwise it crashes python as a punishment Nov 20 15:46:31 haha Nov 20 16:01:11 khem: nice :) Nov 20 16:01:50 btw. should i bring pytest recipe to core ? Nov 20 16:02:10 there are few other python modules in core needing it Nov 20 16:03:59 CGO_LDFLAGS will also need more fixes in go patch Nov 20 16:12:53 khem: I think we'll have to Nov 20 16:13:07 khem: yes, the go patch is exploding on the AB :( Nov 20 17:58:02 On a yocto system, where does the `file` come from? Tried `oe-pkgdata-util find-path /usr/bin/file`, but got "ERROR: Unable to find any package producing path /usr/bin/file". Nov 20 17:59:38 manuel1985: probably the file recipe? Nov 20 18:02:31 Yeah seems to be this: "/meta/recipes-devtools/file" Nov 20 18:04:15 Thanks Nov 20 18:09:25 Still puzzled why `oe-pkgdata-util find-path /usr/bin/file` didn't tell me this. The path is correct. Nov 20 18:14:38 because you hadn't build file yet? Nov 20 18:14:46 it looks at packages, but if you haven't built it, then it can't know Nov 20 18:14:57 the file *recipe* just says that it packages /usr/bin/* Nov 20 18:14:59 which isn't helpful Nov 20 18:17:15 rburton: Got it, thank you! Will take care not to use wildcards in FILES variable Nov 20 18:18:19 well, do Nov 20 18:18:28 because the alternative is maintainer pain Nov 20 18:19:22 probably a long shot, but anyone have experience with syslinux not getting correct usb geometry and rebooting? Nov 20 18:19:24 :) Nov 20 18:21:52 according to syslinux wiki, the symptom of syslinux showing the copyright message and giving up could be a sign that BIOS detection of USB geometry has gone wrong...this happens approx 1/10 times on otherwise rock stable OS...been working on the problem for days Nov 20 18:24:21 I'm afraid no :( Nov 20 18:26:12 I'm just curious, if I compile a simple hello world executable for my host system, "file" says "ELF 64-bit LSB pie executable", but if yocto builds it for qemux86-64, it says "ELF 64-bit LSB shared object". Why "shared object"? I can execute it just fine. Nov 20 18:31:10 maybe file is just misreporting? Nov 20 18:34:40 Hmm... that's not satisfactory :/ I think there must be a (complicated, though) reason. `file` and elf and all that stuff is so old, things like that should be fixed since millenia Nov 20 18:35:15 found an post saying that old file might misreport pie executables as shared objects Nov 20 18:36:09 but that newer versions of file don't... Nov 20 18:37:19 what version of file are you using? Nov 20 18:37:36 was fixed in 5.36 apparently Nov 20 18:38:43 bug in 5.34 implementation reports pie executables as pie shared objects Nov 20 18:40:29 5.38 apparantly: `poky/meta/recipes-devtools/file/file_5.38.bb` Nov 20 18:42:02 Great. Well, no. A developer made a commit before the release of 'file' 5.38 that broke that new behaviour, and went back to executable being identified as "shared object". Nov 20 18:42:04 lol Nov 20 18:42:31 https://bkhome.org/news/202010/file-utility-confuses-executable-and-shared-library.html Nov 20 18:47:11 carlsb3rg: Wow, that's what I call commitment. Thank you! Nov 20 18:49:45 Now I just need to get package splitting to work Nov 20 18:51:05 np: I'm stuck with my syslinux/usb geometry problem anyway so might as well help someone else with their issues Nov 20 18:51:24 bbl Nov 20 18:55:13 Cool :) Well, I got yocto to build a minimal hello-world executable using cmake, but it doesn't seem to put anything in the -dbg package. It does put the source into the -src package, though. Nov 20 18:55:13 The recipe has "inherit cmake" but that's it. both the recipe and the cmakelists as well as the C source code are dead simple, can't be related to that. Nov 20 18:55:35 Well, that is, I think it is related to some of the stuff I wrote.. probably I just didnt activate package splitting in the recipe or so Nov 20 18:57:15 But I thought it should be enabled by default Nov 20 18:57:35 manuel1985: does the cmake compile with -g? Nov 20 18:57:44 if it doesn't do that then no symbols to strip Nov 20 18:59:28 assuming the cmakelists are traditional, a recipe for that should be essentially SRC_URI and 'inherit cmake' Nov 20 18:59:30 everything else will just work Nov 20 18:59:41 Yepp it does. I checked the specific cmake invocation in the tmp directory, and it even includes it twice or so I think. Nov 20 18:59:56 maybe its stripping during install? Nov 20 19:00:44 Need to check if the binary is stripped, but I just ran a '-c cleanall' Nov 20 19:01:11 never a need to do that Nov 20 19:01:44 if you want a force a rebuild because you've been poking around the work directories, use -Cunpack Nov 20 19:01:52 otherwise, bitbake will rebuild if there is a need Nov 20 19:02:08 I didn't yet grok when bitbake triggers a rebuild or not. I've got the source code not in a recipe, but underneath the 'files' dir next to the recipe Nov 20 19:02:29 if its in SRC_URI then bitbake will notice it change and rebuild Nov 20 19:02:35 if you change a variable, bitbake will rebuild Nov 20 19:02:41 if a dependency changes, bitbake will rebuild Nov 20 19:03:28 Ok! The binary is stripped. Check it in 'package' dir and 'packages-split' dir. Nov 20 19:03:53 if it is stripped in image/ then your cmakelists is doing that Nov 20 19:04:41 There it is 'with debug_info, not stripped' Nov 20 19:06:53 That's some good info, though. What's the difference between the 'build' and the 'image' directory? The 'build' directory seems to be where cmake put it's output Nov 20 19:06:57 yes Nov 20 19:07:02 build/ is where cmake does the build Nov 20 19:07:15 image is where "cmake install" is pointed at Nov 20 19:07:41 fwiw i just built taglib to verify cmake+debuginfo didn't break somehow Nov 20 19:07:43 taglib-dbg: Nov 20 19:07:43 /usr/lib/.debug/libtag.so.1.17.0 Nov 20 19:07:43 /usr/lib/.debug/libtag_c.so.0.0.0 Nov 20 19:07:46 Ahh! Good to know Nov 20 19:07:49 works fine Nov 20 19:08:12 There is a '/1.0-r0/debugsources.list' though. Nov 20 19:08:16 image/ is then cloned to package/ which is then pre-processed for packaging and turned into packages-split/ which is the files split up per-package Nov 20 19:09:24 What does 'pre-processed' mean in that context? Nov 20 19:10:54 I think I'll write an email to the mailing list regarding my issue. I have the same problem with at least one other cmake-build project as well. The simpleechoserver from LetoThe2nd. Nov 20 19:10:59 stripped, compressed, files mangled, whatever Nov 20 19:11:13 I see Nov 20 19:12:44 sounds like either your local setup is a little odd, or cmake is being a pain Nov 20 19:13:01 build taglib and check if that builds debug symbols Nov 20 19:13:08 Well, cmake is definately a pain. Nov 20 19:13:13 if you run something like arch, you may have found a new bug Nov 20 19:13:20 as rolling release distros are good at that Nov 20 19:13:33 Unfortunately just a plain boring debian here :( Nov 20 19:21:27 rburton: Oh wtf... I'm terribly sorry and feel like an idiot right now. It seem to have worked the whole time. The problem was that the debug files are put into a hidden directory ".debug" and `tree` doesn't display them by default. Only with the `-a` switch. I set every other tool (file manager, `ls`) so that hidden files get displayed by default, so I didn't think about that. Nov 20 19:21:40 lol Nov 20 19:21:44 yeah Nov 20 19:21:44 glad that's sorted ;) Nov 20 19:22:09 So much time wasted due to this. 2-3 hrs yesterday as well. Nov 20 19:22:42 Well, thank you again Nov 20 19:22:44 ! Nov 20 19:22:53 anyway I mean Nov 20 19:23:44 i like fd-find + https://github.com/jez/as-tree myself Nov 20 19:23:48 * kergoth yawns Nov 20 19:24:47 ah written in Rust, cant be bad :) Nov 20 19:32:44 :) i like that as-tree feels very unix in philosophy. can just find | as-tree, too. does one job Nov 20 19:32:51 fd is just nice to use Nov 20 19:33:40 written in Rust, but with Bazel .. mixed feelings Nov 20 19:33:57 s/but/built/g Nov 20 19:34:24 What does fd | as-tree do different than fd | tree? Didn't get it from the README.md Nov 20 19:34:46 s/fd/find/g Nov 20 19:35:19 normal tree won't be able to create tree from paths printed by find I think Nov 20 19:36:11 sorry it does Nov 20 19:38:49 manuel1985: for looking at what packages are created, use bitbake instead of digging around temp/ Nov 20 19:39:09 manuel1985: oe-pkgdata-util list-pkg-files -p [recipename] Nov 20 19:39:46 that actually works if you wipe tmp then bitbake the recipe, which will just pull from sstate and there won't be anything in temp/ to look at Nov 20 19:45:32 Thanks! Was already wondering how I can bitbake a recipe and still have nothing show up in tmp ;) Nov 20 21:11:58 tmp is just the build area, if its already build, nothing appears Nov 20 22:55:53 I am using the build instructions from https://hub.mender.io/t/asus-tinker-board/45 and I get this after an hour: https://pastebin.com/raw/aCuHRADi Nov 20 22:58:29 TuxBlackEdo: I suspect you have something wrong because I don't think the tinkerboard uses grub Nov 20 22:59:23 agreed Nov 20 22:59:32 TuxBlackEdo: Ah it's grub-native (e.g. grub for your host) Nov 20 22:59:37 Whats your build machine Nov 20 22:59:54 Ubuntu 20.04 Nov 20 23:00:08 5.4.0-45-generic Nov 20 23:00:21 VERSION="20.04.1 LTS (Focal Fossa)" Nov 20 23:02:55 TuxBlackEdo: Huh, weird Nov 20 23:03:09 What version of Yocto are you using? Nov 20 23:04:13 thud Nov 20 23:06:18 TuxBlackEdo: Hmm, not sure then.... Do you specifically need mender, or are you just trying to get something on the tinkerboard? Nov 20 23:06:29 I dont need mender Nov 20 23:06:36 just trying to get it on the tinkerboard Nov 20 23:06:46 TuxBlackEdo: Ah, you know what, I bet 20.04 is too new for Thud Nov 20 23:07:08 oh ok, would 18.04 work better? Nov 20 23:07:45 Probably... there is a list of supported distros somewhere. Honestly, if you just need a build on the tinkerboard you could build something newer Nov 20 23:08:07 I've built gatesgarth for tinkerboard just this morning :) Nov 20 23:08:49 i'll try that Nov 20 23:09:00 TuxBlackEdo: I *think* all you need is poky, meta-arm, and meta-rockchip **** ENDING LOGGING AT Sat Nov 21 02:59:56 2020