**** BEGIN LOGGING AT Tue Jun 18 02:59:57 2019 Jun 18 09:21:52 New news from stackoverflow: Building meta-virtualization layer in yocto Jun 18 10:05:12 smurray, fray, armpit: My gitsm issue was with azure-umqtt-c so fd27ab6 looks very relevant. I cherry-picked that and 30fe86d, threw away my build dir (including downloads cache) and tried a clean build. That worked :) Jun 18 10:07:35 paulbarker: we're missing some backports to 1.40? Jun 18 10:08:53 A pair of gitsm fixes: fd27ab6 and 30fe86d in bitbake Jun 18 10:09:14 There was some brief discussion here last night Jun 18 10:15:15 paulbarker: are those already in 1.42? Jun 18 10:15:26 paulbarker: I can backport them to 1.40 if so and you've tesed Jun 18 10:19:47 RP: 30fe86d is already in 1.42. Looks like the one I need isn't though, fd27ab6 is only in master and needs backporting to 1.42 as well Jun 18 10:20:02 I've tested with both cherry-picked to 1.40 Jun 18 10:20:37 Speaking of backporting, I sent two patches for thud a week ago and I haven't received an answer other than "please clarify", which I did. How is pinging on the ML seen by the community/maintainers? What the recommended waiting time before pinging? Jun 18 10:25:04 qschulz: I think the stable maintainer has been concentrating on warrior and is a touch overloaded :( Jun 18 10:25:25 qschulz: we should get those patches into thud... Jun 18 10:27:41 RP: Absolutely no worries/hurry, thanks for the info :) Jun 18 10:31:19 paulbarker: backported, thanks Jun 18 10:32:29 RP: Thanks, that saves me carrying them locally :) Jun 18 10:41:39 paulbarker: as the bitbake maintainer and knowing the history of those patches (and the tests) I can feel ok about fast tracking that Jun 18 10:42:24 RP: fd27ab6 probably also wants to go into 1.42 then Jun 18 10:42:53 paulbarker: gah, I thought they were in 1.42 Jun 18 10:43:09 30fe86d is, fd27ab6 isn't Jun 18 10:43:24 paulbarker: thanks, sorted Jun 18 11:12:50 Hi all, what is the best way to set the default MACHINE ? Jun 18 11:26:24 in your distro config Jun 18 11:26:49 if you haven't got as far as writing a distro config then 1) consider if you should and 2) local.conf Jun 18 11:35:50 rburton: why in the distro config? (outside of some toolchain selection/features enablement, I don't see (because I don't know) any more use for distro config). for me it's unrelated, what am I missing? Jun 18 11:36:35 its all about the context really. i have a default in site.conf. Jun 18 11:40:26 rburton_: thank you! Jun 18 11:40:50 but for a serious use, site.conf setting machine is stupid Jun 18 11:40:55 because you'll have a distro config to set it Jun 18 11:42:02 rburton_: we define MACHINE= before bitbake here Jun 18 11:42:18 thats the 'one shot override' way Jun 18 11:42:22 local.conf is better Jun 18 11:42:22 and in my previous company we used to modify directly in conf/local.conf Jun 18 11:43:05 As you said, depend on the context, we have multiple different MACHINE so it kinda makes sense to pass it in the env Jun 18 11:43:08 is it for this build only? in the environment when running bitbake. for all builds in this immediate configuration only? local.conf. all builds on this machine? site.conf is a shared location. all builds for this product? the distro conf Jun 18 11:43:37 rburton_: ah, very interesting Jun 18 11:45:10 rburton_: thanks! Jun 18 11:53:04 Has anyone seen an issue where teestimage fails with "WARNING: core-image-sato-1.0-r0 do_testimage: Qemu ended unexpectedly" Jun 18 11:53:24 inside the data dump, are shell commands that supposedly don't exist Jun 18 11:53:31 thats qemu crashing, the other logs hopefully have more context? Jun 18 11:53:50 doing a simple runqemu shows it working Jun 18 11:58:41 the logs in tmp/log/runtime-hostdump/201906180026_qemu/host_00_* show "/bin/sh: df: command not found" Jun 18 11:58:48 or similar Jun 18 11:59:00 when I do runqemu, open the shell, df works perfectly Jun 18 11:59:19 is there another place I could find logs of what might have happened? Jun 18 11:59:52 btw, seeing this on 3 different systems on both x86 and arm64 Jun 18 12:00:05 so odds are high that I misconfigured something Jun 18 12:11:03 while looking at runqemu, I wonder if we should toggle the kvm to always be enabled and have a nokvm if we explicitly don't want it Jun 18 12:22:10 jonmason: I'd ignore those logs Jun 18 12:22:29 jonmason: can you share the log.do_testimage somewhere? Jun 18 12:23:25 jonmason: those logs just show those things aren't present in the image which isn't an issue Jun 18 12:23:37 * RP has the same thing here Jun 18 12:25:35 https://pastebin.com/bzEewMbx Jun 18 12:27:19 jonmason: subprocess.CalledProcessError: Command '('sudo', '/home/jdm/yocto/poky/scripts/runqemu-ifup', '1000', '1000', '/home/jdm/yocto/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin')' returned non-zero exit status 1. Jun 18 12:27:30 jonmason: its failing to do with network device setup Jun 18 12:27:34 yup, I just saw that Jun 18 12:27:59 well, that explains it :( Jun 18 12:28:12 I'm stupid Jun 18 12:28:13 thanks Jun 18 12:28:14 jonmason: I use sudo `which runqemu-gen-tapdevs ` 1000 sharedsource 4 tmp/sysroots-components/x86_64/qemu-helper-native/usr/bin Jun 18 12:28:24 presetup the tap devices Jun 18 12:28:52 you probably want 1000 instead of sharedsource Jun 18 12:29:30 I think I saw something in the docs about the taps being setup, but didn't connect that it could've been the issue Jun 18 12:30:51 jonmason: the options are to setup in advance or let it use sudo Jun 18 12:45:31 I think we are going to have to disable Python PGO for reproducible builds :( Jun 18 12:52:49 JPEW: ah. I can imagine why this may be an issue :( Jun 18 12:53:01 JPEW: could we copy in a cached profile? Jun 18 12:53:26 RP: Yes we should be able to. I was reading some posts on line and that was a recommendation Jun 18 12:54:21 I think the real questions is where it would be kept Jun 18 13:10:16 JPEW: alongside the python recipe? How big is it? Jun 18 13:10:28 ... checking Jun 18 13:13:37 2 MB ish Jun 18 13:19:26 JPEW: hmm, bit larger than I'd have liked Jun 18 13:19:52 JPEW: put in a separate repo and pull it in as a source file? Jun 18 13:20:50 Ya, I think that would work. It would probably have to be re-generated every time python was updated? Jun 18 13:21:10 Or rather *should* be regenerated every time Jun 18 13:23:13 JPEW: yes, it would need that. We could write the recipe in such a way it generates if a source isn't specified? Jun 18 13:23:35 there is some kind of not quite fully formed idea here :) Jun 18 13:24:18 Ya, fair enough. I'll see if it is workable Jun 18 13:24:54 I think this is the last non-reproducible build in core-image-minimal (I still have to submit a bunch of patches....) Jun 18 13:26:52 JPEW: that sounds very cool :) Jun 18 14:38:50 RP: is there an example of a recipe that creates an optional package ? or is it something that i should just allow a package to be empty, or populated based on a variable ? Jun 18 14:39:11 I'm trying to finish up my tweaked linux-headers/linux-source additional to kernel-devsrc. Jun 18 14:39:23 and want to avoid the full linux-source copy, unless someone really wants it. Jun 18 14:40:00 I'm reusing all the infrastructure from kernel-devsrc for most of the work, and wanted to avoid making a separate recipe, or churn things into a .inc. Jun 18 14:40:01 hmmm. Jun 18 14:40:17 * zeddii ponders Jun 18 14:41:58 zeddii: you could make it a PACKAGECONFIG ? Jun 18 14:43:46 zeddii: does anything RDEPEND on the optional package if it's built? Jun 18 14:43:59 nope. Jun 18 14:44:11 it is just something you can install if you want to suffer the bloat of full kernel source :D Jun 18 14:44:30 okay, I'd say go for the empty package if so, but if not seems fine either way Jun 18 14:45:57 I'll try something and put out a RFC. I'm sure a patch will get comments. I was just trying to get close to the right thing before sending. Jun 18 14:46:29 zeddii: my fear is world builds pulling in a separate recipe Jun 18 14:46:55 this is probably going to be a testing matrix problem regardless though :( Jun 18 14:47:04 yah. you really don't want this to run unless you've asked for it. it is the entire thing we ran away from years ago. Jun 18 14:47:21 RP: agreed. Did you want to be pointed at the bugzilla ? I mentioned that when asked for the support. Jun 18 14:47:48 zeddii: I've tried to back you when this comes up. I can do so again somewhere... Jun 18 14:47:57 zeddii: I remember worlds of pain Jun 18 14:48:08 I indicated that it was for reference, since we can't have 3 different ways to build on-target modules times all of our architectures. Jun 18 14:48:30 if the existing devsrc isn't working, we should tweak it, or folks can carry their own recipes. Jun 18 14:48:48 anyway. what I have seems reasonable, I was just unwilling to do a full source copy every time. Jun 18 14:49:16 zeddii: we don't need to and it was hugely painful on the testing infrastrcture Jun 18 14:49:29 * zeddii doesn't think that a few missing files here and there over a span of a year are considerable effort for devsrc when compared to the horror of the old approach :D Jun 18 14:50:07 zeddii: people don't have to generally deal with that horror so complaining about the current situation is much easier to comprehend :/ Jun 18 14:50:16 zeddii: I'm seeing this a lot Jun 18 14:50:21 heh. agreed. Jun 18 14:50:51 like "where is kernel 5.1", 5.0 EOL'd all of 12 days ago!! Jun 18 14:50:56 its the kind of thing which makes me just want to give up and walk away, I get quite depressed about it Jun 18 14:51:51 it's the luxury of only have to care about one arch, or a few targets. Jun 18 14:51:56 * zeddii doesn't have that. Jun 18 15:05:08 I heard there is a command for bitbake to enter the build environment of a recipe Jun 18 15:05:11 what is it? Jun 18 15:09:07 ayaka. it is a task for a recipe: bitbake -c devshell Jun 18 15:10:18 zeddii, I see, I used it before Jun 18 15:10:32 something it won't enter the build workspace of a recipe Jun 18 15:10:38 but it works for some recipe Jun 18 15:11:08 what may cause those recipes won't be enter into proper place? Jun 18 15:12:21 it drops into whatever ${B} is for a recipe IIRC. Jun 18 15:15:10 https://autobuilder.yocto.io/pub/non-release/ Jun 18 15:20:25 zeddii, I would check thank you Jun 18 15:45:21 RP, there was a doc patch https://lists.yoctoproject.org/pipermail/yocto/2019-June/045599.html Jun 18 15:45:37 is there a problem, I wanted to include it in the warrior update Jun 18 15:57:17 armpit: need to ask scott about that Jun 18 16:18:02 hello folks Jun 18 16:18:17 we use gcc mingw on linux to cross compile our windows software. Jun 18 16:18:48 and we maybe want to evaluate to use yocto to compile our windows software. this would mean building a gcc-cross that targets windows, and uses a HOST of linux Jun 18 16:19:18 is this feasible at all? difficulty level? Jun 18 16:20:41 litb: its possible, currently we generate SDKs which run on windows/mingw hosts and are used to build linux apps ( opposite of what you want ) but there has been effort to do the options you are looking for Jun 18 16:21:26 and with some success, its possible to generate the SDK and build some code, but this is not upstreamed or a common usecase Jun 18 16:21:54 khem, i guess i could build on that work, since as an intermediary step, it would need to compile a windows-targetting compiler. I could use that build steps to generate the gcc-cross , i guess? Jun 18 16:22:37 today we can target for mingw Jun 18 16:22:41 khem, i have seen that. i think it's the meta-mingw layer Jun 18 16:22:49 litb: have a look at the meta-mingw layer, yes Jun 18 16:22:52 but the resulting cross compiled code target is linux Jun 18 16:24:15 and last year I did do few patches to target mingw code generation as well IIRC I have posted them for meta-mingw Jun 18 16:24:38 khem, hm, i see. maybe the .deb thing or some other tools in yocto will get into trouble since artifacts are not anymore elf/.a files Jun 18 16:24:49 khem, ah, nice Jun 18 16:25:15 actually it works pretty smoothly after toolchain is working, I was at a point where I was trying to build bash Jun 18 16:25:23 for windows :) and I gave up Jun 18 16:25:45 khem: I don't remember seeing those patches on the ML Jun 18 16:25:53 currently we're using MXE, and we would need to compile the linux things wrapped in a package-less recipe using EXTRA_IMAGEDEPENDS or something Jun 18 16:26:04 JPEW: I did send something probably common patches Jun 18 16:26:04 s,linux things,windows things, Jun 18 16:26:55 khem, ah cool, so maybe we could teach it to use our MXE toolchain and it will work all out Jun 18 20:53:40 New news from stackoverflow: Can I create symbolic links from a Yocto recipe for a file that doesn't exist yet Jun 18 23:20:50 zeddii: https://pastebin.com/raw/PQcGzDes Jun 18 23:21:18 thats when building qemuarm kernel on master Jun 19 01:05:52 see the recent pull request about ptest. It isn’t something I merged. Jun 19 01:12:43 but I’ll see about cleaning it up tomorrow. Jun 19 02:54:26 New news from stackoverflow: Failed to bitbake docker in Yocto 4.9.88 with meta-virtualization layer Jun 19 02:57:37 oi **** ENDING LOGGING AT Wed Jun 19 02:59:57 2019