**** BEGIN LOGGING AT Wed Nov 11 03:02:41 2020 Nov 11 07:37:17 yo dudX Nov 11 07:48:42 good morning LetoThe2nd, everybody Nov 11 09:21:41 what's the difference between these three options? https://github.com/crops/docker-win-mac-docs/wiki Nov 11 09:21:50 poky, extensible SDK and toaster? Nov 11 09:22:25 wyre: poky is a classic full build structure with cli interface. Nov 11 09:22:57 wyre: esdk is an sdk environment (on steroids) targetted at a specific machine/distro/image triplet. Nov 11 09:23:15 wyre: toaster is a full build structure with web interface. Nov 11 09:24:10 and what triplet are poky or toaster based on? Nov 11 09:24:32 none, they are universal Nov 11 09:25:11 may i recommend looking at some introductory material? https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Nov 11 09:25:17 so you mean esdk is for building yocto for an specific triplet? Nov 11 09:25:37 there is also an episode which shows build vs. sdk vs. esdk Nov 11 09:25:37 of course, thank you LetoThe2nd 😄 Nov 11 09:26:44 (e)sdk means, it is a kit that can be used to develop hardware for a specific target (the mentioned triplet). as opposed to a full build where you can define the target. Nov 11 09:27:20 LetoThe2nd, to develop hardware? 🤔 Nov 11 09:27:52 i wrote: "a specific target (the mentioned triplet)" Nov 11 09:45:05 why I'm getting still the same output for 'uname -a' inside poky container? 🤔 Nov 11 09:46:24 wyre: Because the poky container still uses your real kernel (as far as I know). You are isolated in terms of filesystem and so on, but not in the kernel Nov 11 09:46:39 wyre: because containers share the kernel. in a nutshell Nov 11 09:46:50 oh, I see Nov 11 10:28:18 While nowhere is open due to coronavirus restrictions here I decided to keep myself busy by sharing some of my Yocto Project hacking sessions Nov 11 10:28:48 The first video shows the process of creating & debugging a couple of recipes for applications written in Rust: https://www.youtube.com/watch?v=N5UPFo4JiTs Nov 11 10:29:15 I won't be spamming the videos on here often so subscribe over there if you want to see more :) Nov 11 10:31:06 paulbarker: LetoThe2nd will be sad you didn't contact him to do some Twitch session and advertise it properly :p Nov 11 10:31:33 huh what, already busy preparing advertisement tweet for paulbarker Nov 11 10:31:55 Live streaming on twitch doesn't really fit how I'm planning to work on these Nov 11 10:32:49 paulbarker: I was just joking, it's nice to see different learning supports :) thx for publishing it! Nov 11 10:32:57 I want to be able to edit out long build times or combine a couple of shorter hacking sessions into a single video where it makes sense Nov 11 10:36:42 editing is work. Nov 11 10:36:45 * LetoThe2nd doesn't like. Nov 11 10:37:31 reminds me i need to do the announcement video for the upcoming sessino Nov 11 10:37:41 Editing definitely adds some work but I don't mind it at the moment Nov 11 10:38:10 if there is one thing that i am extremely short on these days, then its spare time for things like that. Nov 11 10:39:41 I've ended up with a little more spare time, no pubs open and no live music so needed something new to learn Nov 11 10:40:17 yeah, different life situation altogether. Nov 11 11:00:08 Hi Folks. I am working on a recipe for a SDK, where I could use some hints for how you would do it. Nov 11 11:00:51 Notice the idea is to use yocto for releasing the SDK, as it need to be cross compiled to ARM, to a number of yocto versions. Nov 11 11:01:49 frosteyes: the SDK is meant to *target* arm, or the SDK is mean to *run* *on* ARM? Nov 11 11:02:47 For x64 it is compiled using clang / cpp on a normal ubuntu with the following commands. Nov 11 11:02:53 cmake .. -DCMAKE_BUILD_TYPE=Debug && cmake --build . --target LinuxTargets --config Debug Nov 11 11:02:55 cmake -DBUILD_TYPE=Debug -DCOMPONENT=Cpp -P cmake_install.cmake Nov 11 11:04:57 LetoThe2nd: the release is normal a zip file for windows or tar.gz file for linux Nov 11 11:05:30 So if possible, make yocto create a "custom" tar.gz beside the rpm Nov 11 11:05:50 frosteyes: i'm not sure that i understand you. Nov 11 11:06:03 Will elaborate :) Nov 11 11:08:01 The SDK targets windows (x64), Linux (X64 and arm64), iOS (arm64). Nov 11 11:09:13 As customers for arm64 is using yocto (And I have yocto expericence from our firmware), I am looking into letting yocto do the cross compilation.. Nov 11 11:10:00 (Target is later to deliver the SDK for the customers using yocto with a recipe, so it handles dependencies etc). Nov 11 11:10:49 The --target part for build is handled by OECMAKE_TARGET_COMPILE = "LinuxTargets" Nov 11 11:11:12 in the recipe, but what about the -DCOMPONENT part for the install Nov 11 11:11:15 cmake -DBUILD_TYPE=Debug -DCOMPONENT=Cpp -P cmake_install.cmake Nov 11 11:11:54 I was thinking on abusing OECMAKE_TARGET_INSTALL with something like OECMAKE_TARGET_INSTALL = "install -DCOMPONENT=Cpp" Nov 11 11:13:07 But it does not work - as the install command is with "cmake --build ... --target install" Nov 11 11:18:12 The easist is properly just to do a custom do_install Nov 11 13:18:53 Hello. I would like to ask for help with removing file `machine-id` from my default etc image. I tried to localize which package adds this file into rootfs but I couldn't find it. I tried to use ROOTFS_POSTPROCESS_COMMAND in my image.bb. It apperantly fires the function, but `machine-id` is still there. The rason I want to delete the file is that I have systemd service with `ConditionFirstBoot=true`. Nov 11 13:32:27 koty0f: are you using read-only rootfs? If so it seems that file is created using ROOTFS_POSTPROCESS_COMMAND too, so if your deletion is run after the creation it should work I guess. Nov 11 13:32:52 How did you add your command to ROOTFS_POSTPROCESS_COMMAND ? Nov 11 13:39:12 koty0f: use oe-pkgdata-util find-path /path/to/file to find which package provides the file Nov 11 13:52:44 RP: I have a question about reproducibility of -native items. When I run diff -uNr reproducibleA/tmp/sysroots-components/x86_64/ reproducibleB/tmp/sysroots-components/x86_64/ on the directory that the reproducible test leaves behind, I get a ton of lines like Nov 11 13:52:54 Binary files reproducibleA/tmp/sysroots-components/x86_64/binutils-cross-x86_64/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld and reproducibleB/tmp/sysroots-components/x86_64/binutils-cross-x86_64/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld differ Nov 11 13:52:58 Does it matter? Nov 11 13:53:55 kanavin_home: I'm not sure we've ever tested native reproducibility Nov 11 13:54:10 kanavin_home: target is of much more interest Nov 11 13:54:57 kanavin_home: the relocation of the binaries would cause problems for the test so I think we'd have to do something trickier with the test Nov 11 13:55:25 RP: the native binaries seem to have paths encoded in them, e.g. for the linker above, if I run strings on both binaries, and compare the output, I see lots of things like: Nov 11 13:55:25 -/home/akanavin/build-st/reproducibleA/tmp/work/x86_64-linux/binutils-cross-x86_64/2.35-r0/recipe-sysroot-native/usr/lib/x86_64-poky-linux/debug Nov 11 13:55:25 +/home/akanavin/build-st/reproducibleB/tmp/work/x86_64-linux/binutils-cross-x86_64/2.35-r0/recipe-sysroot-native/usr/lib/x86_64-poky-linux/debug Nov 11 13:55:56 RP: I just started to fix a few of the bigger items in target world repro failures, and had to pause and think if -native matters :) Nov 11 13:56:08 wanted to confirm that it doesn't Nov 11 13:56:49 kanavin_home: its something we need to look at but shouldn't affect what we're doing for world. The loader paths for example will always differ for native. We might not be passing the right path relocation things for debug symbol relocation in native Nov 11 13:57:41 kanavin_home: thinking about it, host gcc version will matter a lot too Nov 11 13:58:02 i.e. this will never work on the autobuilder Nov 11 13:58:21 RP: right, I was just wondering if native reproducibility has a larger effect on hash equiv, than e.g. something like piglit or webkit, which almost nothing depends on Nov 11 13:58:39 kanavin_home: hashequiv is why we should try and improve it Nov 11 14:00:45 erbo: No the rootfs should be rw. Here is the recipe https://pastebin.com/raw/GiB35nBw. I also tried to comment out lines from `oe-core/meta/classes/rootfs-postcommands.bbclass` just to try if it will change anything. Nov 11 14:01:34 qschulz: ERROR: Unable to find any package producing path /etc/machine-id Nov 11 14:03:52 koty0f: then the only possible explanation would be that the image recipe is creating it somehow (as my wild guess is that it's not outputting packages in Yocto?) Nov 11 14:07:05 koty0f: a small git grepo tells me systemd-conf is doing it. Have you cleaned the tmpdir before running oe-pkgdata-util? I seem to recall you need a valid tmpdir for it to work? Nov 11 14:08:01 seems like the systemctl used for image construction can create machine-id, see poky/meta/recipes-core/systemd/systemd-systemctl/systemctl Nov 11 14:28:59 smurray: I swapped BASELIB like you suggested, the sdk works correctly on the native machine now, but I get a kernel panic during boot on the target. Still trying to track down whats going wrong there. Nov 11 14:30:05 christner: heh, I'm hoping that's unrelated Nov 11 14:37:16 sgw: The QMP spec says that lines have to be terminated with CR_LF: I wonder if thats what's messing up your communication Nov 11 14:54:35 Morning gang! Nov 11 14:55:42 sgw: Morning Nov 11 14:55:47 * LetoThe2nd ponders gang programming sgw Nov 11 14:56:12 JPEW: this initial releasing of qemu via the same commands Nov 11 14:56:16 and seems to work Nov 11 14:56:31 More than one command? Nov 11 14:56:36 LetoThe2nd: you can gang up on me if you want, I will gladly accept help Nov 11 14:57:08 JPEW: sequential commands similar to the way dump monitor works dump_monitor Nov 11 14:57:41 sgw: Hmm, odd. I would recommend letting python encode the JSON as I said in the email Nov 11 14:58:47 I had not read email yet been in meetings this morning Nov 11 14:58:48 sgw: i'll ask down in mfg if they can spare some of their old gear. i'm surprised that you like it, but hey... https://www.ebay.de/itm/TEXAS-INSTRUMENTS-MSP430-Gang-Programmer-MSP-GANG430-C6/153918662997?hash=item23d6446955:g:CnEAAOSwyd1er8tI Nov 11 14:58:55 Nov 11 14:59:08 hehe Nov 11 14:59:10 sgw: That's fair, I just sent it a few minutes ago :) Nov 11 15:29:03 JPEW: I will dig into that change later today or in the week, that was part of my thought process (using the Python JSON object) Nov 11 15:32:26 sgw: Ya. JSON is a good interchange format, but it's not for humans... it's just to hard to write correctly by hand Nov 11 15:33:32 Yeah, I just need to spend some time learning about it. This monitor has been a fun re-introduction to bitbake and YP! Nov 11 15:33:58 zeddii: kanavin_home: please don't start any builds on the autobuilder in the next few hours Nov 11 15:35:03 how comes that in the first time in my life i now mentally picture zeddii and kanavin_home sitting in front of some machine that automatically builds tiny little toy houses? Nov 11 15:45:58 is there a way to have add a global environment variable visible to everyone? Nov 11 15:46:16 into the OS image that is Nov 11 15:48:10 ack'd Nov 11 15:48:26 Ad0: Would it work to add it to /etc/profile? Nov 11 15:49:04 good question Nov 11 15:49:35 will systemd respect that for example=? Nov 11 15:49:43 Ad0: I don't think so Nov 11 15:50:09 things like docker has to know about it to pass it on to the containers Nov 11 15:50:19 docker is started via systemd Nov 11 15:50:40 maybe I can put the same var into both systemd base configs AND profile Nov 11 15:51:03 Windows has a system-wide environment Nov 11 15:53:46 RP: can I run private builds over ssh? Nov 11 15:54:05 e.g. command line stuff under my own account Nov 11 16:01:02 kanavin_home: yes Nov 11 16:03:02 RP: I am digging deeper and deeper into go's non-reproducibility :) Nov 11 16:05:51 kanavin_home: sounds like fun. I'm wrestling buildbot :/ Nov 11 16:08:29 RP: I started one. should I cancel it ? or you can cancel it Nov 11 16:09:41 khem: I'll sort. That explains a few things :/ Nov 11 16:10:27 I can wait. cancel it Nov 11 17:02:14 ross / RP: any concerns / comments on Luca's dbus split patch? https://lists.openembedded.org/g/openembedded-core/message/144190?p=,,,20,0,0,0::Created,,dbus,20,2,0,77989696 Nov 11 17:02:32 environment var is probably the wrong way too, I just need a way to identify 2 versions of the hardware, so I can put some file there on the fs for each device type or probe for devices that aren't on the other, or if there is some standard way in yocto to tag that kind of variables Nov 11 17:03:52 bluelightning: -tools would normally be -bin, surely Nov 11 17:04:12 i guess there's multiple candidates for bins Nov 11 17:04:53 bluelightning: I was going to ask and defer to rburton Nov 11 17:09:18 rburton: we're not consistent, I see -tools in some recipes too Nov 11 17:09:53 but we could of course start with this change if we want to standardise on -bin Nov 11 17:10:39 just an observation Nov 11 17:10:48 its not all binaries, so tools is arguably better Nov 11 17:11:12 * RP wishes he could figure out "simple" buildbot stuff Nov 11 17:24:39 some recipes now depend on fortran support but we do not enable it by default in gcc I wonder if it makes sense to have a global metadata knob to define supported language runtimes from gcc Nov 11 17:25:42 what's the build overhead of enabling fortran in gcc-cross Nov 11 17:25:49 might be worth just enabling by default Nov 11 17:26:04 but yes, i'd say a PACKAGECONFIG for the languages toggle would be sensible :) Nov 11 17:30:13 yeah overhead is low, since its all about building libgfortran Nov 11 17:30:46 i say lets just enable it by default Nov 11 17:30:55 at least that will stop the periodic mails about making it work Nov 11 17:31:16 true, me picks the chain saw Nov 11 17:45:54 be a good redneck, pick the right viscosity bar oil... Nov 11 17:50:33 khem: do we really want to encourage fortran? Nov 11 17:52:59 For a short while I was filled with panic that the autobuilder now goes cyan coloured Nov 11 17:54:11 Running 'devtool modify u-boot-imx' on Ubuntu 20.04 ends up with an error "Exception: ModuleNotFoundError: No module named '_sysconfigdata'". Stacktrace starts at "devtool-source.bbclass', lineno: 68, function: devtool_post_unpack". I have tried 'devtool modify' on a couple of other recipes and it works in those cases but not with u-boot-imx. Familiar to anyone? Nov 11 17:55:12 RP: turning it on in gcc won't cause much of a hit and i prefer quietly encouraging to helping people turn it on ;) Nov 11 18:17:54 yeah we dont Nov 11 18:32:08 sakoman: I've restarted your build. Nov 11 18:32:23 RP: thanks! Nov 11 18:32:32 khem, kanavin_home: autobuilder is back now. Hopefully with backwards compatibility for older helper code Nov 11 18:32:56 https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/2717 is a little glimpse at the future Nov 11 18:33:24 or https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/2967 and its cyan step :) Nov 11 18:33:53 sakoman: I'd check its building the right thing. I still don't trust rebuild buttons Nov 11 18:37:14 RP: seems OK to me Nov 11 18:52:50 RP: ok let me start a build Nov 11 21:20:30 Is there way to create a ptest image tar file, similar to debugFS. Basically on a formal build I want to create production image, debug-image and ptest-test image. This will allow designer to untar the ptest image on the target and run unit/integration test . The production image can be verified easily. Nov 12 00:15:40 khem: you still around? I've noticed an oddity with gcc-runtime and x86 where libatomic/etc override -march (via configure.tgt). Have you seen this? looks like qemux86 avoids compile errors cause it explicitly adds -msse Nov 12 00:16:40 yes we try to target generic tunes but it is configured for specific Nov 12 00:18:42 khem: so it is correct for libgomp to be compiled like so? ... -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse ... -march=i486 -mtune=i686 ... libgomp/alloc.c Nov 12 00:55:48 which tuning are you using Nov 12 00:56:26 generally we nullify what gcc runtime wants to do Nov 12 01:59:31 khem: sorry didn't see your message. The args i just posted are with qemux86, the tune i was using (which has build failures) is custom but is basically just CCARGS "-march=westmere -mtune=btver2 -mfpmath=sse" ontop of tune-x86 Nov 12 02:01:37 khem: i think the problem is that this x86 check in configure.tgt (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/configure.tgt;h=1863287fa0d4f66cbb4c2421808e4208bdf9e50c;hb=HEAD#l82) is adding those args which are undesirable. It seems to be specific to only a few of libgomp/libatomic/etc. Nov 12 02:09:25 nrossi: only think this will need is atomic instructions and we do not build for i386 so we should be ok to remove this Nov 12 02:12:52 khem: you mean remove the addition of the args? or should "--with-arch" be plumbed in for i386? Nov 12 02:17:32 patch the tgt file to not use it Nov 12 02:18:44 khem: ok, i presume that is something that is not upstreamable correct? so just an oe-core patch yes? Nov 12 02:33:55 I think its just for oe since we use own cflags Nov 12 02:35:36 khem: is it worth changing it so the detection checks for march in CFLAGS like it checks for -m64/etc.? could make it upstreamable? Nov 12 02:36:24 or is CFLAGS overrides with march just not something upstream supports? Nov 12 02:46:34 yeah if we can implement the logic where it will set it based upon whats in CFLAGS that will perhaps work upstream too Nov 12 02:47:05 ok, will have a look into it :) **** ENDING LOGGING AT Thu Nov 12 02:59:56 2020