**** BEGIN LOGGING AT Thu Apr 25 03:00:02 2019 Apr 25 09:10:13 so, throwing this out there as someone here might now. Is there a small, standalone, user-initiated tftp server for linux? Ideally, it'd run command-line without daemonizing and would read configuration either from arguments or from a small cfg file not placed globally (i.e. in /etc) Apr 25 09:12:51 miwa: busybox tftpd not fitting the bill? Apr 25 09:14:19 is it ok to inherit a class in recipe multiple time? Apr 25 09:14:48 xtron: for what use? Apr 25 09:16:07 LetoThe2nd: even busybox's tftpd's documentation says "should be used as an inetd service", so no I guess even if there might be a way to run it in the foreground? Apr 25 09:16:08 LetoThe2nd, making some code common, there is a case when a recipe can require 'common.inc' 'other.inc' both inherit kernel for example Apr 25 09:16:47 miwa: "should" does not mean "must" Apr 25 09:16:53 miwa: i'd just give it a try Apr 25 09:17:46 xtron: i don't get it. do you mean you want multiple require lines? in that case: yes. do you mean you want to require the very same include multiple times? in that case: rethink your code. Apr 25 09:18:23 LetoThe2nd, obviously these *.inc files inheriting other stuff too, but 'inherit kernel' is an example of common include Apr 25 09:19:03 xtron: sounds very much like "rethink your code" Apr 25 09:21:07 LetoThe2nd, I'm using multiple require lines, Apr 25 09:31:19 Hi. Is it normal behaviour to have a setscene tasks run for a recipe and then mid-building an image that said recipe to actually start building? I'm having an issue with my kernel recipe. I can see the logs in the SetScene part that it successfully executes do_package_write_ipk_setscene, but then when it get to the RunQueue stage is starts doing fetch/compile/etc/install and do_deploy (but not do_package). Apr 25 09:31:41 The problem is that the zImage that ends up in the image is different than the one in tmp/deploy/images/.... Apr 25 09:32:23 This confuses me, I assumed that when bitbake computes the tasks it knows before hand that a recipe it's either pulled from sstate or is completely build, not doing half-half Apr 25 09:32:33 This is on sumo, btw Apr 25 09:55:11 Sorry, thud Apr 25 11:09:59 blitz00: What's the kernel recipe? Does it inherit the deploy bbclass? Apr 25 11:16:51 kanavin: there is a patch mentioned on the netdev list which might fix the python test hang Apr 25 11:17:10 kanavin: someone else ran into a problem too Apr 25 12:51:01 paulbarker: it only inherits kernel Apr 25 12:51:49 paulbarker: but yes, kernel.bbclass inherits deploy Apr 25 12:54:39 blitz00: Ok, my first guess was that you should be seeing do_deploy_setscene as well as do_package_write_ipk_setscene. But if the deploy bbclass is inherited that should be handled unless there's something messing with the do_deploy function Apr 25 12:54:58 Perhaps you need to post this one to the mailing list with some more info Apr 25 13:04:06 blitz00: it suggests something has a dependency which isn't being met from the sstate covered tasks and hence something triggers a kernel build Apr 25 13:04:52 blitz00: the system will gracefully handle it by rebuilding it which is what its designed to do (graceful fallback), it can sometimes be tricky to work out which dependency causes it though Apr 25 13:14:11 RP: ah okay. So restoring from sstate and then rebuilding is normal behaviour. I always assumed that the system figures out at the beginning if something will be used from sstate or built, and not run both setscene and runqueue tasks Apr 25 13:15:19 RP: however, it seems the triggered rebuild is not complete, not all tasks are run at the rebuild, hence my assumption that I end up with different zImage in different places. Let me pastebin something Apr 25 13:15:26 blitz00: its suboptimal but not an error as such depending on what was in the sstate cache Apr 25 13:16:14 blitz00: you shouldn't get a different zImage, it may get changed if the zImage task hasn't run yet though Apr 25 13:16:36 (probably do_deploy for the case you're talking about) Apr 25 13:26:43 RP: https://pastebin.com/a4Tq9mED and https://pastebin.com/D0F72dvY Apr 25 13:26:59 what bugs me is that do_deploy does run at rebuild Apr 25 13:27:08 but I see no do_package_ipk, nothing after do_install Apr 25 13:28:15 at this point I don't understand if the kernel in the image is the wrong one, or the one in deploy. Problem is that I have signed modules enabled, and it using the kernel in deploy it doesn't boot, but the one in /boot works Apr 25 13:28:47 that means that either the modules in the image are themselves the old ones or are the new built ones Apr 25 13:30:07 on my setup I should be able to boot with the kernel in the image or the one in deploy, it shouldn't matter... unless I get a build like this one, when the kernel from deploy is bad because it contains a different signature than the modules Apr 25 13:37:26 RP, regarding the manual sdk test. maybe its a special case selftest but lives in a "release" dir Apr 25 13:38:19 armpit: not sure I follow? :/ Apr 25 13:38:48 that manual test can be automated using the selftest classes Apr 25 13:39:09 but you don't want to run it every time you run selftests Apr 25 13:39:33 it needs to be aware of where the release artifacts are Apr 25 13:40:32 so have a release dir might make sense to indicate things to be run for release or at release time Apr 25 13:40:54 * armpit maybe a patch might make more sense ; ) Apr 25 13:41:53 armpit: I understand now Apr 25 13:41:59 we have a 24 hour crashme test that might be better suit living there too Apr 25 13:42:18 armpit: with regard to the 24 crashme, I'm quite happy to move that to be a "BSP" test Apr 25 13:42:35 armpit: its more poking at hardware than software Apr 25 13:42:42 yeah, it should be because its very BSP specific Apr 25 13:43:15 armpit: Perhaps for release we should have a separate release sanity test as part of the final release process? Apr 25 13:43:52 sure Apr 25 13:45:39 * armpit might even automate the release process ; ) Apr 25 13:45:49 armpit: there are scripts already Apr 25 13:46:09 yeah. but the the AB do it Apr 25 13:46:10 armpit: digging into them is something I haven't gotten around to yet Apr 25 13:46:47 armpit: the AB already preps the release directory to a large extent Apr 25 13:47:19 release notes? Apr 25 13:47:37 armpit: would always have to be a two pass process Apr 25 13:48:34 what are VM for ; ) Apr 25 13:50:01 * armpit hmmm, bsp layers containing there own tests... Apr 25 13:50:28 armpit: we need to get the QA test results back, merge them, sort the QA report header, bug reports and release notes - can't all be automated Apr 25 13:52:14 armpit: btw, which stable branch am I meant to be merging? You have so many different ones now :( Apr 25 13:54:06 armpit: I saw you added the LTP test results to resulttool. Are there logs that would be useful to pull out with the new 'resulttool log' subcommand? Apr 25 13:57:13 armpit: oh, its an oecore one now isn't it. Perhaps the older poky-contrib stable ones should be tidied up? Apr 25 13:57:18 JPEW, should be if you understand LTP raw logs. Apr 25 13:58:05 RP, openembedded-core-contrib/log/?h=stable/sumo-next Apr 25 13:58:20 for sure.. now I have go figure out thud. Apr 25 13:59:42 RP, my pull requests no longer come from poky Apr 25 14:01:19 RP.. you got my last Thud pull request Apr 25 14:02:13 armpit: right, can we remove the stable/xxx-next from poky to stop confusing me then please? :) Apr 25 14:02:20 yes Apr 25 14:02:37 I can't do that but you or MH can Apr 25 14:02:46 armpit: you can't? :/ Apr 25 14:02:46 I use stable/*-nmut for builds Apr 25 14:03:01 contrib.. let me check Apr 25 14:04:34 armpit: if not I'll clean them up Apr 25 14:06:45 looks like I can remove mine Apr 25 14:07:43 sumo & thud -next removed Apr 25 14:10:55 armpit: thanks Apr 25 14:13:17 RP: any hints on how can I force it to run all tasks if it starts building the kernel? Seems that it's missing do_package_ipk Apr 25 14:14:00 blitz00: why would it need to run all tasks? Apr 25 14:14:38 either the sstate checksum changes and it needs to rebuild or it doesn't and the output is identical Apr 25 14:14:58 Is that isn't the case, the checksum has a bug and there are missing dependencies Apr 25 14:15:33 Right, it considers it needs a rebuild, but I do not see all the tasks being rebuilt: https://pastebin.com/D0F72dvY - I see do_install and do_deploy, but no do_package Apr 25 14:15:47 and the kernel in the image seems it comes from the ipk restored from sstate Apr 25 14:16:04 blitz00: I'm still not seeing a bug Apr 25 14:18:20 I'm not saying there is one... maybe I'm doing something funky (i'm using uboot-sign and kernel-fitimage classes as well,. so maybe those are doing something funky). Still I do not understand why /boot/zImage is not the same as tmp/deploy/images/zImage Apr 25 14:18:46 well, as you say, one is package manager and one is from do_deploy Apr 25 14:18:50 And since I'm seeing do_compile/do_install/do_deploy actually run Apr 25 14:19:06 I was expecting to see a do_package as well Apr 25 14:19:29 * zeddii is watching the activity on RPs TCP hang thread .. fingers crossed that it finally gets attention Apr 25 14:19:32 and as you mention the kernel is getting rebuilt. In theory the rebuild should give the same output. The fact it isn't is a reproducibility issue Apr 25 14:19:45 zeddii: yes, would be interesting to try that patch with our hang Apr 25 14:20:47 blitz00: Its something like there being a dependency change A <- B <- C <- D where D is an sstate task and A-C are not. Something in your setup is depending on A, B or C and hence its causing them to rerun Apr 25 14:21:05 blitz00: since D already built and D doesn't need to be rebuild its only rebuilding A-C Apr 25 14:21:57 s/change/chain/ Apr 25 14:21:57 the rebuild is different because the module signing key changes at every build. So, generally speaking, when something rebuilds and re-runs do_install there is a requirement that do_package runs? Apr 25 14:21:57 blitz00: when a task reruns it should have exactly the same output for any given set of inputs Apr 25 14:22:02 you've broken than rule if you change signing key Apr 25 14:22:03 I see, that helps. I suspect uboot-sign and kernel-fitimage doing something funky. I've seens some fixes in warrior for those and I've tried to backport them Apr 25 14:23:49 Hmm, yes, I'm letting the kernel build generate the key - I'm not providing one Apr 25 14:27:51 uboot's do_deploy depends on the kernel's do_deploy cf. uboot-sign.bbclass Apr 25 14:32:12 RP focus Apr 25 14:32:39 armpit: coming Apr 25 14:50:21 kanavin: fancy being the perl maintainer? as you sent the rewrite? Apr 25 14:53:32 * armpit heheh Apr 25 14:54:20 shock discovery was that i'm the owner :) Apr 25 15:00:58 hmm, kernel module signing seems to not work with sumo. does one need to disable kernel modulue stripping or something? Apr 25 15:04:15 mcfrisk: most likely yes. thud iirc has code to not strip signed modules. Apr 25 15:04:19 (which sucks) Apr 25 15:20:46 rburton: thanks, I'll have a look at the patches in thud or master branch Apr 25 15:21:55 * Piraty curses Xilinx Apr 25 16:51:54 Piraty, would did they do this time? Apr 25 17:07:46 mcfrisk: in thud it kind of works, meaning that it will not strip them anymore, but you end up with fat modules. Add EXTRA_OEMAKE += "INSTALL_MOD_STRIP=1" in your recipe to let the kernel strip them at install Apr 25 17:21:10 New news from stackoverflow: How to do a clean rebuild of Linux kernel modules in Yocto? **** ENDING LOGGING AT Fri Apr 26 02:59:56 2019