**** BEGIN LOGGING AT Tue Nov 10 02:59:56 2020 Nov 10 08:02:50 yo dudX Nov 10 08:24:51 RP: adding world to reproducibility test: Nov 10 08:24:51 2020-11-10 02:44:59,206 - oe-selftest - INFO - Reproducibility summary for deb: same=11038 different=87 missing=0 total=11125 Nov 10 08:24:51 2020-11-10 02:51:20,339 - oe-selftest - INFO - Reproducibility summary for ipk: same=11038 different=87 missing=0 total=11125 Nov 10 08:25:29 could be worse Nov 10 08:25:36 87 is not too bad is it Nov 10 08:25:43 oe-core world? Nov 10 08:25:46 yeah Nov 10 08:26:03 and that's 87 debs, not 87 recipes Nov 10 08:26:23 got a link for the report? Nov 10 08:26:39 2020-11-10 02:44:59,206 - oe-selftest - INFO - Reproducibility summary for deb: same=11038 different=87 missing=0 total=11125 Nov 10 08:26:40 2020-11-10 02:51:20,339 - oe-selftest - INFO - Reproducibility summary for ipk: same=11038 different=87 missing=0 total=11125 Nov 10 08:26:40 2020-11-10 02:51:36,565 - oe-selftest - INFO - Running diffoscope Nov 10 08:26:40 2020-11-10 04:14:56,566 - oe-selftest - INFO - Keepalive message Nov 10 08:26:40 2020-11-10 05:38:16,567 - oe-selftest - INFO - Keepalive message Nov 10 08:26:40 2020-11-10 07:01:36,567 - oe-selftest - INFO - Keepalive message Nov 10 08:26:40 2020-11-10 08:24:56,567 - oe-selftest - INFO - Keepalive message Nov 10 08:26:56 diffoscope still crunching, no idea when it's going to finish Nov 10 08:27:57 I wonder if we should drop the rpm/deb/ipk test for the entire recipe space and just do one recipe in rpm/deb/ipk, then world in just one packaging format Nov 10 08:28:35 have we seen packaging-specific reprod regressions once all the initial problems were fixed? Nov 10 08:29:14 akanavin@ubuntu1804-ty-3:~/build$ ls repro-world/oe-reproducible-20201109-z46h7z0_/packages/reproducibleA/tmp/deploy/ipk/core2-64/ Nov 10 08:29:14 acpica-src_20200925-r0_core2-64.ipk     go-dep-dev_0.5.4-r0_core2-64.ipk                igt-gpu-tools-dbg_1.25+git0+d16ad07e7f-r0_core2-64.ipk  libsecret-dev_0.20.4-r0_core2-64.ipk              ruby_2.7.2-r0_core2-64.ipk Nov 10 08:29:14 bootchart2-doc_0.14.9-r0_core2-64.ipk   go-dep-staticdev_0.5.4-r0_core2-64.ipk          igt-gpu-tools_1.25+git0+d16ad07e7f-r0_core2-64.ipk      libsecret-src_0.20.4-r0_core2-64.ipk              spirv-tools-dev_2020.5-r0_core2-64.ipk Nov 10 08:29:14 cwautomacros_20110201-r0_core2-64.ipk   go-dep_0.5.4-r0_core2-64.ipk                    kea-dbg_1.7.10-r0_core2-64.ipk                          libswresample3_4.3.1-r0_core2-64.ipk              swig-dbg_3.0.12-r0_core2-64.ipk Nov 10 08:29:14 dtc-dbg_1.6.0-r0_core2-64.ipk           go-helloworld-dbg_0.1-r0_core2-64.ipk           kea-src_1.7.10-r0_core2-64.ipk                          libswscale5_4.3.1-r0_core2-64.ipk                 swig_3.0.12-r0_core2-64.ipk Nov 10 08:29:15 dtc-misc_1.6.0-r0_core2-64.ipk          go-helloworld-dev_0.1-r0_core2-64.ipk           kea_1.7.10-r0_core2-64.ipk                              llvm-dbg_10.0.1-r0_core2-64.ipk                   systemd-bootchart-dbg_233+git0+fe1c5e41e6-r0_core2-64.ipk Nov 10 08:29:15 dtc-staticdev_1.6.0-r0_core2-64.ipk     go-helloworld-staticdev_0.1-r0_core2-64.ipk     libaprutil-1-0_1.6.1-r0_core2-64.ipk                    llvm-dev_10.0.1-r0_core2-64.ipk                   systemd-bootchart_233+git0+fe1c5e41e6-r0_core2-64.ipk Nov 10 08:29:16 dtc_1.6.0-r0_core2-64.ipk               go-helloworld_0.1-r0_core2-64.ipk               libaprutil-1-dbg_1.6.1-r0_core2-64.ipk                  llvm_10.0.1-r0_core2-64.ipk                       vim_8.2-r0_core2-64.ipk Nov 10 08:29:16 epiphany-dbg_3.38.1-r0_core2-64.ipk     go-runtime-dev_1.15.3-r0_core2-64.ipk           libaprutil-1-ptest_1.6.1-r0_core2-64.ipk                lttng-tools-dbg_2.12.2-r0_core2-64.ipk            vulkan-samples-dbg_git-r0_core2-64.ipk Nov 10 08:29:17 epiphany_3.38.1-r0_core2-64.ipk         go-runtime-staticdev_1.15.3-r0_core2-64.ipk     libavcodec58_4.3.1-r0_core2-64.ipk                      lttng-tools-ptest_2.12.2-r0_core2-64.ipk          vulkan-samples-dev_git-r0_core2-64.ipk Nov 10 08:29:17 ffmpeg-dbg_4.3.1-r0_core2-64.ipk        go-runtime_1.15.3-r0_core2-64.ipk               libavdevice58_4.3.1-r0_core2-64.ipk                     ovmf-dbg_edk2-stable202008-r0_core2-64.ipk        vulkan-samples-src_git-r0_core2-64.ipk Nov 10 08:29:18 ffmpeg_4.3.1-r0_core2-64.ipk            go_1.15.3-r0_core2-64.ipk                       libavfilter7_4.3.1-r0_core2-64.ipk                      ovmf-dev_edk2-stable202008-r0_core2-64.ipk        vulkan-samples-staticdev_git-r0_core2-64.ipk Nov 10 08:29:18 gcr-dbg_3.38.0-r0_core2-64.ipk          groff-dbg_1.22.4-r0_core2-64.ipk                libavformat58_4.3.1-r0_core2-64.ipk                     ovmf-shell-efi_edk2-stable202008-r0_core2-64.ipk  vulkan-samples_git-r0_core2-64.ipk Nov 10 08:29:19 gcr_3.38.0-r0_core2-64.ipk              groff-src_1.22.4-r0_core2-64.ipk                libavresample4_4.3.1-r0_core2-64.ipk                    parted-ptest_3.3-r0_core2-64.ipk                  webkitgtk-src_2.30.2-r0_core2-64.ipk Nov 10 08:29:59 rburton: yes, usually during version updates repro test exposes them Nov 10 08:30:12 or actually, no Nov 10 08:30:31 there's no rpm based repro test btw, only deb/ipk Nov 10 08:30:45 oh i thought we did rpm already Nov 10 08:31:20 might be worth copy/pasting the report into a google drive so multiple people can pick them off one at a time Nov 10 08:31:45 akanavin@ubuntu1804-ty-3:~/build$ ls repro-world/oe-reproducible-20201109-z46h7z0_/packages/reproducibleA/tmp/deploy/ipk/qemux86_64/    Nov 10 08:31:45 perf_5.8.13-r9_qemux86_64.ipk Nov 10 08:33:32 do we have a ticket for world reproducibility? Nov 10 08:33:40 not afaik Nov 10 08:46:45 kanavin_home: i want the above quote out of context... Nov 10 08:57:35 when i use "devtool modify" and do a git rebase -i devtool-base, devtool detects re-worded patches only when i change the patch subject. otherwise changed commit messages are not detected. is this in purpose? Nov 10 08:58:04 it is also unable to detect changes in patch order :( Nov 10 09:10:01 derRichard: no that is not on purpose... I suspect something has been broken Nov 10 09:10:08 kanavin_home: that isn't as bad as I expected Nov 10 09:11:24 bluelightning: you mean the reworded case? i fear the reorderung issue is deeply flawed. Nov 10 09:12:42 i have some ideas how to improve devtool. what is the right mailinglist to discuss? Nov 10 09:14:21 derRichard: oe-core Nov 10 09:15:17 thx :) Nov 10 09:24:24 RP: the only issue is that diffoscope scales poorly, it has 1G of packages to compare, and still crunching after some 6 hours with no indication where it is now Nov 10 09:24:44 (half of that is llvm-dbg) Nov 10 09:28:09 kanavin_home: I suspect it should skip "big" packages, that is more likely the issue Nov 10 09:32:10 yeah llvm-dbg webkit-dbg etc are going to be huge Nov 10 09:34:23 diffoscope has a lot of options but I can't see "don't dissect files bigger than X if they are different" Nov 10 09:35:26 i assume it does a checksum comparison first before pulling the files apart Nov 10 09:36:23 rburton: send patches :) Nov 10 10:03:33 Hi all once again, asking if someone has an idea or a recipe i can peep into in order to install a python3 wheel based package Nov 10 10:30:31 Hi ! I am building disk images for x86 using WIC, and I am trying to use bootctl on those (the bootloader is systemd-boot, of course). However, bootctl complains that the ESP does not have the correct type. After looking at the GPT table with fdisk, I found that WIC creates an ESP with the "Microsoft Reserved Data" type, where bootctl expects a type that is "EFI System". Is there a way I can tell Nov 10 10:30:33 WIC to use this partition type instead ? Nov 10 10:59:55 Hello Nov 10 11:00:02 I have Yocto Linux running on arm32 machine. I am connecting to it using SSH (root access) and I would like to be able to figure out (from the shell) if the framebuffer is in the sleep power mode. Nov 10 11:00:15 I have naively tried "cat /sys/class/graphics/fb0/blank" however it returns nothing... any idea how to figure out the state of framebuffer over ssh? Nov 10 11:06:45 EmoChicken: this is neither arm nor ssh related at al, probably more if the specific fb driver actually exports that information. look at the driver if it has/provides such, and then trace the information to userspace. it might even include ioctl'ing on /dev/fb0... Nov 10 11:09:10 EmoChicken: depending on the specific HW it might even require traing the power/backlight controls of the fb, so be sure to also look at the DT Nov 10 11:12:22 LetoThe2nd: I am able to read the actual content of fb0 (bit array of OLED screen) using cat, however I have no idea how to figure out if it is in the sleep mode. I am also using the device as a "user" so I do not support the OS and I might not have the information about the drivers :( TBH i don't even understand it at this low level Nov 10 11:14:26 I am writing something like a "remote control" for our IoT device... part of that is to show the content of OLED screen (that works) but I am missing the information about "screen saver mode" Nov 10 11:16:40 EmoChicken: then i'd say, its time to get in touch with your HW/OS vendor. Nov 10 11:17:07 EmoChicken: as it really "depends" (TM) Nov 10 11:17:41 LetoThe2nd: I guess I will. Ok, thanks. Nov 10 11:18:31 EmoChicken: concerning the ioctl possibility, look at https://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/fb.h also Nov 10 11:19:39 LetoThe2nd: ok, thanks Nov 10 11:19:43 * LetoThe2nd lunches out Nov 10 13:11:46 Hey! I want bitbake to build the same target for multiple machines, automatically. Currently, I have build/conf/machine1.conf and build/conf/machine2.conf and call bitbake twice, with each -R flag. It works, but is it … correct? Nov 10 13:30:07 jmiehe: You could try using multiconfig there. http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html?highlight=multiconfig#building-images-for-multiple-targets-using-multiple-configurations Nov 10 13:31:47 paulbarker: thanks for the link, also I just found out about BB_ENV_EXTRAWHITE and how MACHINE is a part of it by my default env. so I can ditch the confs and call "MACHINE=foo bitbake bar" :) Nov 10 13:46:13 argh ENABLE_UART forces uart console in config.txt Nov 10 13:46:56 SERIAL = "${@oe.utils.conditional("ENABLE_UART", "1", "console=serial0,115200", "", d)}" Nov 10 13:49:34 I guess my machine conf is executed before meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc Nov 10 13:49:55 Ad0: of course, it's a configuration file Nov 10 13:50:01 yeah Nov 10 13:50:25 so the inc file for raspberry just sets the SERIAL Nov 10 13:51:02 I have to override the entire CMDLINE variable Nov 10 14:01:10 Ad0: what are you trying to achieve? Nov 10 14:01:22 not make it enable serial console Nov 10 14:01:24 hehe Nov 10 14:01:41 I have survived till now by just mounting it and editing the file but it's annoying Nov 10 14:02:00 ENABLE_UART does other things as well Nov 10 14:02:21 putting enable_uart into the config.txt and I actually want that I suppose Nov 10 14:02:47 so since SERIAL is not ?= but = , then I would need to override CMDLINE which is ?= Nov 10 14:02:48 Ad0: create a new machine based on the raspberrypi one Nov 10 14:03:00 I did Nov 10 14:03:13 I just needed to find what variable that I could actually override :D Nov 10 14:03:58 Ad0: it does not matter if SERIAL is loosely set or not Nov 10 14:04:05 you can always override it later on Nov 10 14:04:27 really Nov 10 14:04:29 the variables are expanded after they have been all parsed (except if there is a := somewhere) Nov 10 14:04:53 https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L29 Nov 10 14:05:12 when that file loads won't it just overwrite what I set ? Nov 10 14:05:30 that's my recollection, but if I'm wrong, I can already tell you what I said will be corrected :) Nov 10 14:05:48 Ad0: it will, just set SERIAL after this file has been included? Nov 10 14:06:13 look on line 30 Nov 10 14:06:18 it uses it immediately Nov 10 14:06:26 Ad0: no it does not Nov 10 14:06:35 because it's not := Nov 10 14:06:35 CMDLINE ?= "dwc_otg.lpm_enable=0 ${SERIAL} root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" Nov 10 14:07:06 paulbarker: oh, multiconfig is like 200% cleaner, thanks! <3 Nov 10 14:07:10 it still does not Nov 10 14:07:13 won't it set CMDLINE if it's not set from befor? Nov 10 14:07:17 it "references" it Nov 10 14:07:25 15:04:29 qschulz | the variables are expanded after they have been all parsed (except if there is a := somewhere) Nov 10 14:08:17 paulbarker: thank you :) Nov 10 14:08:20 I see they are expanded not at that point Nov 10 14:08:37 I need to "get it" right before they are used then Nov 10 14:08:42 get in* Nov 10 14:09:54 Ad0: just set SERIAL in a bbappend Nov 10 14:11:03 or whatever you actually want to modify :) Nov 10 14:11:27 hehe I already have linux-raspberrypi bbappend actually Nov 10 14:11:40 but I feel that the vars are scattered all over the place and I have to remember them Nov 10 14:12:39 so setting SERIAL = "null" in linux-raspberrypi_%.bbappend would do it then ?= Nov 10 14:13:36 SERIAL = "" I'd say? Nov 10 14:16:01 yeah Nov 10 14:16:08 you can say anything really Nov 10 14:16:22 was just a bit scared that "" would fall back to /dev/serial0 or something :D Nov 10 14:16:54 SERIAL = "console=" Nov 10 14:18:13 I could also define my own variable like FORCE_SERIAL in my machine conf and have logic for it in the bbappend but Nov 10 14:19:21 set up multiconfig, got: »ERROR: Nothing PROVIDES 'mc:foo:core-image-minimal'. Close matches: core-image-minimal, core-image-minimal-dev« Nov 10 14:21:43 I have BBMULTICONFIG = "foo bar" in my local.conf Nov 10 14:26:44 jmiehe, what's your dir structure like ? Nov 10 14:27:36 local.conf , multiconfig -> foo.conf, bar.conf Nov 10 14:27:42 Ad0: yes Nov 10 14:28:24 foo.conf contains only override values for local.conf, right? Nov 10 14:30:11 that I don't know Nov 10 14:30:44 why do you want to use it ? :) Nov 10 14:32:08 "You need to create a single configuration file for each build target (each multiconfig). Minimally, each configuration file must define the machine and the temporary directory BitBake uses for the build. " Nov 10 14:32:36 seems like there is no inheritance? Nov 10 14:32:42 foo.conf and bar.conf contain different MACHINE values for which the build config differs by a tiny bit. Nov 10 14:33:08 ok Nov 10 14:33:19 hm … then it's back to --postread them on bitbake call Nov 10 14:33:23 what I did was to actually make my own layer, and specify the machines and go that route Nov 10 14:33:54 if you intend to share your project with others local.conf route is not recommended I think Nov 10 14:34:00 since you mix local and common settings Nov 10 14:34:12 rburton: I put diffoscope out of its misery, I will address the biggest (size wise) repro fails, then try again to get a report on the rest Nov 10 14:35:00 Ad0: reasonable Nov 10 14:37:59 Ad0: can I inherit a machine config from another layer for that purpose? Nov 10 14:38:03 jmiehe: rule of thumb: if you need to version/share local.conf, you're doing it wrong. Nov 10 14:38:27 jmiehe: in that case, you need to either create a new machine, or a new distro :) Nov 10 14:38:31 I started out with local config since A LOT of the tutorials only uses it Nov 10 14:38:54 Ad0: that's "fine", but once you need to share your work, can't use it anymore :) Nov 10 14:39:04 yeah haha Nov 10 14:39:09 qschulz: I'm not, I'm building from scratch in a CI environment Nov 10 14:39:37 jmiehe, I duplicated my machine Nov 10 14:40:13 jmiehe: you can require/include anything by using relative paths from any layer's root (say you have meta-rpi/recipes-kernel/kernel/linux-raspberry.inc, you require recipes-kernel/kernel/linux-raspberry.inc) Nov 10 14:40:25 not sure if you can require / include other machine.conf Nov 10 14:41:07 of course you can :) Nov 10 14:41:33 So I have meta-vendor/conf/machine/machine-foo.conf and want to inherit from meta-custom/conf/machine/machine-foo-custom.conf … Nov 10 14:42:15 I'd "require ../../../meta-vendor/conf/machine/machine-foo.conf"? eew Nov 10 14:42:28 require conf/machine-foo.conf Nov 10 14:42:46 err conf/machine/machine-foo.conf Nov 10 14:43:17 All conf/ folders are mashed together? Nov 10 14:43:21 yes Nov 10 14:43:56 you have #@TYPE: Machine Nov 10 14:43:57 etc and then require the machine you want to inherit from Nov 10 14:45:25 especially working on CI I would immediately start working on my own layer with machines etc Nov 10 14:49:29 We have multiple layers already Nov 10 14:50:12 just no custom machines defined yet … it's all scripted :^) Nov 10 14:50:35 That's why I'm cleaning up :^) Nov 10 15:00:59 I just posted some patches to bitbake-devel to enable hiearchal hash equivalence servers. I can't remember who all was interested in that, but I'd appreciate some feedback :) Nov 10 15:13:25 what does mean this? https://docs.yoctoproject.org/ref-manual/ref-system-requirements.html#supported-linux-distributions Nov 10 15:13:40 are those the distributions where you can build yocto? Nov 10 15:13:57 I mean, are those the supported distributions to build yocto proeject? Nov 10 15:14:15 wyre: yes? Nov 10 15:14:26 wyre: anything else you're probably on your own Nov 10 15:14:52 wyre: note that you should check on the manuals of your yocto revision to know which ones are supported Nov 10 15:15:01 other distros probably work, but those are the ones that are tested Nov 10 15:15:21 but just for building process, right? Nov 10 15:15:35 did someone tried on ArchLinux? Nov 10 15:15:36 of course Nov 10 15:15:39 yeah, it breaks all the time Nov 10 15:16:02 wyre: just use pyrex or crops for building with containers if you're on archlinux Nov 10 15:16:03 arch linux aggressively upgrades, so breaks the build fairly often Nov 10 15:16:05 rburton, oh, 😞 Nov 10 15:16:16 or, use arch, and send fixes :) Nov 10 15:16:18 So if I do 'require conf/machine/machine-foo.conf' in 'meta-custom/conf/machine/machine-foo-custom.conf', which has '#@NAME: machine-foo-custom', it errors out with »Nothing PROVIDES 'virtual/kernel': linux-vanilla PROVIDES virtual/kernel but was skipped: incompatible with machine machine-foo-custom (not in COMPATIBLE_MACHINE), …« Nov 10 15:16:24 This is a rabbit hole. Nov 10 15:16:48 qschulz, I didn't know about pyrex or crops Nov 10 15:16:52 jmiehe: add machine-foo to overrides in machine-foo-custom Nov 10 15:17:12 pyrx do you mean? Nov 10 15:17:18 where's the docs for machine configs anyway? Nov 10 15:18:08 jmiehe: MACHINEOVERRIDES =. "machine-foo:" is the magic Nov 10 15:18:16 basically "this machine is also this other machine" Nov 10 15:19:11 wyre: lots of people use arch, they either use a container running something more stable, or live with the fact that they might be the first person to discover that eg a binutils upgrade in arch breaks the build Nov 10 15:19:15 rburton: what's =. again? Nov 10 15:19:23 jmiehe: += without whitespace Nov 10 15:19:41 wyre: https://github.com/garmin/pyrex Nov 10 15:19:41 well, its prepend without whitespace Nov 10 15:19:53 jmiehe: and IIRC, it should be put before any include/require in your machine configuration file Nov 10 15:21:56 kergoth, what about crops? Nov 10 15:22:42 https://www.google.com/search?hl=en&q=yocto%20%22crops%22 :) i don't have as much expereince with that one, sorry Nov 10 15:26:43 wyre: I'm one of the Arch Linux users here and also started using CROPS, due to weird errors I got when trying things natively Nov 10 15:27:08 dleppich, and how is going using CROPS? Nov 10 15:27:30 can you provide me more info? (about crops, I mean, official docu or a github link) Nov 10 15:29:53 wyre: It is a docker container image. Github (https://github.com/crops/poky-container). In this wiki (https://wiki.yoctoproject.org/wiki/TipsAndTricks/CropsCLIContainers) there is a hint at the end how to run it (the command with the $(pwd)). Nov 10 15:30:57 wyre: All you have to do is to start in the docker container before using all the commands (e.g. bitbake). When the shell is opened, you proceed as if you were working natively on your own machine) Nov 10 15:31:05 rburton, qschulz: thank you! Nov 10 15:31:12 dleppich, so it's a docker container with a specific setup for yocto building process? Nov 10 15:31:12 wyre: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-to-use-crops as well Nov 10 15:31:44 base distro + the build requirements Nov 10 15:32:18 wyre: Yes. It is a ubuntu based image with all build dependencies installed. It also has some nice features like setting the user and group id's of the docker user to the correct values, so that files created inside the container are correctly owned outside of the container Nov 10 15:36:17 dleppich, so I guess you have not problems anymore 😄 Nov 10 15:37:21 wyre: At least no architecture or machine specific problems. I'm still quite new to the Yocto project and asking stupid questions from time to time. But using CROPS made me a happier adventurer :D Nov 10 15:38:12 awesome 😊 Nov 10 15:38:43 I'm gonna try it, probably I will be also here asking stupid things in a while, hehe Nov 10 15:39:00 wyre: I started using CROPS when I was asked multiple times if I'm using Arch Linux accidentally after asking a question about one of my issues here Nov 10 15:39:32 oh, I see Nov 10 15:40:47 But the guys in this channel are super friendly and always helped me out :) Never met such a great community before! Nov 10 15:44:20 oh, that's fantastic hehe Nov 10 15:49:38 dleppich: there are probably non-guys here too :) but happy to see you like the community, I agree with you :) Nov 10 15:53:26 what are those all container for? https://hub.docker.com/u/crops/ Nov 10 15:54:29 I mean, what's the difference between crops/poky and crops/yocto for example? Nov 10 16:17:53 qschulz: Yeah, you are totally right. As a non-native english speaker I thought that "guys" would include all genders. Sorry :) Nov 10 16:20:35 JPEW: what's the tool you were mentioning for docs building? "pipen nv" or something? Nov 10 16:20:47 tlwoerner: pipenv Nov 10 16:20:52 thanks Nov 10 16:37:32 sakoman: fyi, just found a gcc patch i failed to backport to dunfell hope to send this week Nov 10 16:38:16 rburton: I'll watch for it! Nov 10 16:54:37 * mcfrisk dives into a rabbit hole, to remove python2. wondering how far this goes, and will I be sane afterwards.. Nov 10 16:55:16 you might find Alice Nov 10 16:57:23 will say hi :) Nov 10 16:57:31 mcfrisk: good luck! Nov 10 16:57:52 neverpanic: I'll drag you along... Nov 10 16:58:05 mcfrisk: hope you're not doing that for the old platform? Nov 10 16:58:27 neverpanic: I'm not that crazy, yet.. Nov 10 16:59:03 mcfrisk: there shouldn't be any dragging required for us, then. Nov 10 16:59:26 does anyone use cmake with in-tree builds? Nov 10 16:59:49 neverpanic: hahaa, good one. check your inbox for newly created tickets... Nov 10 17:02:49 :( Nov 10 17:03:21 rburton: I've seen software fail to build out-of-source with CMake, yes. Not in Yocto, but in other packaging systems, for example doxygen was affected. Nov 10 18:22:37 wyre: crops/poky will dynamically create a user/group for you that matches the workdir. crops/yocto will whatever the default uid:gid the distro uses when creating a user, usually 1000:1000. crops/poky uses crops/yocto, but just does a bit more to try and make it easier to use/experiment. Nov 10 18:26:24 rewitt, you mean will create in my system a user/group? Nov 10 18:26:29 or in the docker container itself? Nov 10 18:30:43 in the container Nov 10 18:31:52 https://www.youtube.com/watch?v=JXHLAWveh7Y&list=PLbzoR-pLrL6pSlkQDW7RpnNLuxPq6WVUR&index=56 if you have spare time to listen to me ramble Nov 10 18:32:41 I tried to do the talk for someone that may have little to no docker/container experience Nov 10 18:32:59 wyre: ^ Nov 10 18:37:00 wyre: There is also https://github.com/garmin/pyrex if you want to try something else. It's a little more "seamless" than crops Nov 10 18:37:52 that's why i use pyrex. essentially transparent once set up, doesn't impact the development workflow Nov 10 18:40:07 I won't advocate for one over the other, because all the times I Nov 10 18:40:27 I've tried to start thinking about consolidating, people yelled at me :) Nov 10 18:41:05 ha. i think it depends on your requirements, really. I can see an argument to use a simpler setup without pyrex for CI jobs, for example, but pyrex for day to day engineering work, perhaps Nov 10 18:43:30 kergoth: IMO CI and dev env should be same for best results Nov 10 18:43:47 fair point, otherwise you could get differences in behavior Nov 10 18:43:49 kergoth: Right, that's what I've always thought, until I need to run devtool, or devshell and those things. I just hate not being able to point to THE solution. Nov 10 18:44:32 pyrex does wrap devtool and the other scripts of that sort. devshell works too as long as you don't mind tmux or screen :) Nov 10 18:50:02 kergoth: I live in tmux and mosh so it works for me. Does pyrex work with runqemu and serial? Nov 10 18:50:59 there's no real need to use runqemu inside the container when you can run it just as well outside the container. it uses the pyrex bitbake wrapper to query the metadata it needs if it needs it Nov 10 18:51:03 * kergoth shrugs Nov 10 18:51:12 rewitt: Ya, it should. It actually bypasses runqemu and lets your run it locally (instead of inside the container) Nov 10 18:51:26 rewitt: Which works because of the magic of uninative ;) Nov 10 18:55:22 rewitt: Yeah, I guess crops is mostly for CI people who don't want the setup parts of pyrex. I do know of users who will run "docker run crops/poky some_other_command_other_than_bash_or_bitbake" Nov 10 18:56:51 JPEW: I suppose if two different tools serves a purpose there is no harm in having two. But perhaps consolidating some of the dynamic user/group creation might be worth investigating. Nov 10 18:57:07 pyrex can wrap any command you want it to, within reason. there's a config file. you can also use pyrex-shell to run arbitrary commands. i use the latter to rsync files out of the volume in the case where i'm building on a host with case insensitive workspace, i.e. on macos Nov 10 18:59:28 It's funny because pyrex behaves a lot like what I had intended when I first made https://www.youtube.com/watch?v=JXHLAWveh7Y&list=PLbzoR-pLrL6pSlkQDW7RpnNLuxPq6WVUR&index=56. i.e. The container starts and then exits Nov 10 18:59:44 Ugh wrong link, https://github.com/crops/yocto-dockerfiles/blob/master/helpers/runbitbake.py Nov 10 19:01:12 And I remember, at the time I was like "I don't want the user to have to do any setup other than install docker", but I don't think that's necessarily a rarity anymore. :) Nov 10 19:23:31 ty rewitt 😄 Nov 10 19:39:31 but I don't get why do you say pyrex is more transparent than crops once set up 🤔 Nov 10 19:40:16 it automatically creates wrapper scripts to run the tools in the container without having to do anything else. 'bitbake' runs bitbake in the container, etc Nov 10 19:40:34 no special setup, no change in your workflow, other than using the pyrex setup script Nov 10 19:41:17 that is, you don' thave to 'enter' the container and use vim, etc in there, or use your own wrapper functions or anything special. you can use your host development tooling and use the wrappers to only run the build inside Nov 10 19:41:27 doing that with crops is workable, it's just less automatic and transparent Nov 10 19:41:41 I used to use my own wrapper scripts with a crops container, for example Nov 10 19:51:48 kergoth, I love vim Nov 10 19:53:06 I think I must read more about pyrex workflow Nov 10 19:56:13 wyre: Just to be clear, you don't have to use vim in the container, you can still access all the files on the host system using vim in a different terminal. The difference is really with crops, I will have two terminals open, one for running bitbake, and one for running every other command. Whereas with pyrex you wouldn't have to do that. Nov 10 19:57:45 rewitt, I guess when you run bitbake you are starting a new building process, right¿ Nov 10 20:19:42 wyre: Yes, or one of the other things bitbake will do such as show you the values of variables in the metadata. Nov 10 21:17:55 hello...what is the difference between Yocto ADT and (e)SDK . Both seem to be providing the same solution Nov 10 21:42:05 rewitt: Ya, some of the stuff Pyrex has to do for the user/group parts are... interesting :) Nov 10 21:51:50 kiwi_29: ADT is a precursor to the SDK and is *just* the compiler+tools. a SDK for an image is compiler, tools, and the libraries/headers for that image Nov 10 22:18:58 thanks rburton then probably SDK is the one which everybody would use...no? what use is adt then ? because target sysroot which contains headers and libs (assuming sdk provides sysroot and not adt) is needed for writing apps that run on target . Nov 10 22:50:01 kiwi_29: correct, nobody should be using the ADT unless they have special needs Nov 11 02:24:08 you can bundle tradition SDK/ADT with eSDK too which is nice for transitioning Nov 11 02:43:47 Rebooting bugzilla short downtime. **** ENDING LOGGING AT Wed Nov 11 03:02:41 2020