Thursday, 2019-04-25

*** falk0n <falk0n!> has quit IRC00:00
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto00:11
*** falk0n <falk0n!> has joined #yocto00:12
*** rburton <rburton!> has quit IRC00:20
*** vineela <vineela!~vtummala@> has quit IRC00:21
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC00:27
*** tgraydon <tgraydon!~textual@> has quit IRC00:31
*** kaspter <kaspter!~Instantbi@> has quit IRC00:38
*** kaspter <kaspter!~Instantbi@> has joined #yocto00:38
*** fatalhalt <fatalhalt!> has joined #yocto00:48
*** gattuso <gattuso!> has quit IRC02:08
yoctiNew news from stackoverflow: Yocto: Nothing provides python-re-native <>02:18
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC02:45
*** gattuso <gattuso!> has joined #yocto02:47
*** kaspter <kaspter!~Instantbi@> has quit IRC03:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:50
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto04:02
*** fatalhalt <fatalhalt!> has quit IRC04:12
*** cvasilak <cvasilak!~cvasilak@2a02:587:810c:1400:8882:b774:41a5:e008> has joined #yocto04:39
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC05:03
*** AndersD <AndersD!> has joined #yocto05:10
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:12
*** agust <agust!> has joined #yocto05:20
*** tprrt <tprrt!~tprrt@> has joined #yocto05:39
*** Bunio_FH <Bunio_FH!> has joined #yocto05:58
*** Bunio_FH <Bunio_FH!> has quit IRC06:09
*** Bunio_FH <Bunio_FH!> has joined #yocto06:09
*** JaMa <JaMa!> has joined #yocto06:17
*** fitzsim <fitzsim!> has quit IRC06:33
*** AndersD <AndersD!> has quit IRC06:37
*** rburton <rburton!> has joined #yocto06:47
*** jeanba <jeanba!~jbl@> has joined #yocto06:51
*** jeanba <jeanba!~jbl@> has left #yocto06:51
*** lusus <lusus!~lusus@> has joined #yocto07:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC07:10
*** florian_kc is now known as florian07:50
*** varjag <varjag!> has joined #yocto08:48
*** dv_ <dv_!> has quit IRC08:54
*** xtron <xtron!~xtron@> has joined #yocto08:55
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto09:00
*** yann <yann!~yann@> has joined #yocto09:04
*** dv_ <dv_!> has joined #yocto09:08
miwaso, 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)09:10
LetoThe2ndmiwa: busybox tftpd not fitting the bill?09:12
xtronis it ok to inherit a class in recipe multiple time?09:14
LetoThe2ndxtron: for what use?09:14
miwaLetoThe2nd: 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?09:16
xtronLetoThe2nd, making some code common, there is a case when a recipe can require '' '' both inherit kernel for example09:16
LetoThe2ndmiwa: "should" does not mean "must"09:16
LetoThe2ndmiwa: i'd just give it a try09:16
LetoThe2ndxtron: 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.09:17
xtronLetoThe2nd, obviously these *.inc files inheriting other stuff too, but 'inherit kernel' is an example of common include09:18
LetoThe2ndxtron: sounds very much like "rethink your code"09:19
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:20
xtronLetoThe2nd, I'm using multiple require lines,09:21
*** blitz00 <blitz00!c1f0f176@gateway/web/freenode/ip.> has joined #yocto09:24
*** Hodhr <Hodhr!> has joined #yocto09:28
*** Hodhr <Hodhr!> has left #yocto09:28
blitz00Hi. 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).09:31
blitz00The problem is that the zImage that ends up in the image is different than the one in tmp/deploy/images/....09:31
blitz00This 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-half09:32
blitz00This is on sumo, btw09:32
blitz00Sorry, thud09:55
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:07
*** rburton <rburton!> has quit IRC10:31
*** rburton <rburton!> has joined #yocto10:32
paulbarkerblitz00: What's the kernel recipe? Does it inherit the deploy bbclass?11:09
RPkanavin: there is a patch mentioned on the netdev list which might fix the python test hang11:16
RPkanavin: someone else ran into a problem too11:17
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC11:18
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:19
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto11:21
*** berton <berton!~berton@> has joined #yocto11:27
*** berton <berton!~berton@> has quit IRC11:38
*** berton <berton!~berton@> has joined #yocto11:39
*** cvasilak <cvasilak!~cvasilak@2a02:587:810c:1400:8882:b774:41a5:e008> has quit IRC11:40
*** cvasilak <cvasilak!~cvasilak@2a02:587:810c:1400:8882:b774:41a5:e008> has joined #yocto11:41
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC11:47
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:49
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:56
*** radsquirrel <radsquirrel!> has quit IRC12:02
*** radsquirrel <radsquirrel!> has joined #yocto12:03
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC12:04
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto12:05
*** rburton <rburton!> has quit IRC12:21
*** rburton_ <rburton_!> has joined #yocto12:21
*** berton <berton!~berton@> has quit IRC12:29
*** kaspter <kaspter!~Instantbi@> has quit IRC12:43
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:44
blitz00paulbarker: it only inherits kernel12:51
blitz00paulbarker: but yes, kernel.bbclass inherits deploy12:51
paulbarkerblitz00: 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 function12:54
paulbarkerPerhaps you need to post this one to the mailing list with some more info12:54
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:01
RPblitz00: it suggests something has a dependency which isn't being met from the sstate covered tasks and hence something triggers a kernel build13:04
*** vineela <vineela!vtummala@nat/intel/x-rgvbhruauepatbng> has joined #yocto13:04
RPblitz00: 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 though13:04
*** xtron <xtron!~xtron@> has quit IRC13:10
blitz00RP: 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 tasks13:14
blitz00RP: 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 something13:15
RPblitz00: its suboptimal but not an error as such depending on what was in the sstate cache13:15
RPblitz00: you shouldn't get a different zImage, it may get changed if the zImage task hasn't run yet though13:16
RP(probably do_deploy for the case you're talking about)13:16
*** vineela <vineela!vtummala@nat/intel/x-rgvbhruauepatbng> has quit IRC13:20
*** vineela <vineela!~vtummala@> has joined #yocto13:23
blitz00RP: and
blitz00what bugs me is that do_deploy does run at rebuild13:26
blitz00but I see no do_package_ipk, nothing after do_install13:27
blitz00at 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 works13:28
blitz00that means that either the modules in the image are themselves the old ones or are the new built ones13:28
blitz00on 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 modules13:30
*** vineela <vineela!~vtummala@> has quit IRC13:32
*** rburton_ <rburton_!> has quit IRC13:36
*** rburton <rburton!> has joined #yocto13:36
armpitRP, regarding the manual sdk test.  maybe its a special case selftest but lives in a "release" dir13:37
RParmpit: not sure I follow? :/13:38
armpitthat manual test can be automated using the selftest classes13:38
armpitbut you don't want to run it every time you run selftests13:39
armpitit needs to be aware of where the release artifacts are13:39
armpitso have  a release dir might make sense to indicate things to be run for release or at release time13:40
* armpit maybe a patch might make more sense ; )13:40
RParmpit: I understand now13:41
armpitwe have a 24 hour crashme test that might be better suit living there too13:41
RParmpit: with regard to the 24 crashme, I'm quite happy to move that to be a "BSP" test13:42
RParmpit: its more poking at hardware than software13:42
armpityeah, it should be because its very BSP specific13:42
RParmpit: Perhaps for release we should have a separate release sanity test as part of the final release process?13:43
* armpit might even automate the release process ; )13:45
RParmpit: there are scripts already13:45
armpityeah. but the the AB do it13:46
RParmpit: digging into them is something I haven't gotten around to yet13:46
RParmpit: the AB already preps the release directory to a large extent13:46
armpitrelease notes?13:47
RParmpit: would always have to be a two pass process13:47
armpitwhat are VM for ; )13:48
* armpit hmmm, bsp layers containing there own tests...13:50
RParmpit: 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 automated13:50
RParmpit: btw, which stable branch am I meant to be merging? You have so many different ones now :(13:52
JPEWarmpit: 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?13:54
RParmpit: oh, its an oecore one now isn't it. Perhaps the older poky-contrib stable ones should be tidied up?13:57
armpitJPEW, should be if you understand LTP raw logs.13:57
armpitRP, openembedded-core-contrib/log/?h=stable/sumo-next13:58
armpitfor sure.. now I have go figure out thud.13:58
armpitRP, my pull requests no longer come from poky13:59
armpitRP.. you got my last Thud pull request14:01
RParmpit: right, can we remove the stable/xxx-next from poky to stop confusing me then please? :)14:02
armpitI can't do that but you or MH can14:02
RParmpit: you can't? :/14:02
armpitI use stable/*-nmut for builds14:02
armpitcontrib.. let me check14:03
*** andrunko` <andrunko`!andrunko@nat/collabora/x-pcjcpyhwhjuawbid> has quit IRC14:03
RParmpit: if not I'll clean them up14:04
armpitlooks like I can remove mine14:06
armpitsumo & thud -next removed14:07
*** rburton <rburton!> has quit IRC14:08
*** rburton <rburton!> has joined #yocto14:09
RParmpit: thanks14:10
*** kaspter <kaspter!~Instantbi@> has quit IRC14:12
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC14:12
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:13
blitz00RP: 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_ipk14:13
RPblitz00: why would it need to run all tasks?14:14
RPeither the sstate checksum changes and it needs to rebuild or it doesn't and the output is identical14:14
RPIs that isn't the case, the checksum has a bug and there are missing dependencies14:14
blitz00Right, it considers it needs a rebuild, but I do not see all the tasks being rebuilt: - I see do_install and do_deploy, but no do_package14:15
blitz00and the kernel in the image seems it comes from the ipk restored from sstate14:15
RPblitz00: I'm still not seeing a bug14:16
blitz00I'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/zImage14:18
RPwell, as you say, one is package manager and one is from do_deploy14:18
blitz00And since I'm seeing do_compile/do_install/do_deploy actually run14:18
blitz00I was expecting to see a do_package as well14:19
* zeddii is watching the activity on RPs TCP hang thread .. fingers crossed that it finally gets attention14:19
RPand 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 issue14:19
RPzeddii: yes, would be interesting to try that patch with our hang14:19
RPblitz00: 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 rerun14:20
RPblitz00: since D already built and D doesn't need to be rebuild its only rebuilding A-C14:21
blitz00the 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?14:21
RPblitz00: when a task reruns it should have exactly the same output for any given set of inputs14:21
RPyou've broken than rule if you change signing key14:22
blitz00I 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 them14:22
*** dreyna <dreyna!> has joined #yocto14:22
blitz00Hmm, yes, I'm letting the kernel build generate the key - I'm not providing one14:23
*** varjag <varjag!> has quit IRC14:24
*** comptroller <comptroller!> has quit IRC14:26
blitz00uboot's do_deploy depends on the kernel's do_deploy cf. uboot-sign.bbclass14:27
armpitRP focus14:32
RParmpit: coming14:32
*** Bunio_FH <Bunio_FH!> has quit IRC14:33
*** comptroller <comptroller!> has joined #yocto14:34
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has joined #yocto14:36
rburtonkanavin: fancy being the perl maintainer? as you sent the rewrite?14:50
* armpit heheh14:53
rburtonshock discovery was that i'm the owner :)14:54
mcfriskhmm, kernel module signing seems to not work with sumo. does one need to disable kernel modulue stripping or something?15:00
rburtonmcfrisk: most likely yes.  thud iirc has code to not strip signed modules.15:04
rburton(which sucks)15:04
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has quit IRC15:05
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has joined #yocto15:06
*** varjag <varjag!> has joined #yocto15:18
*** WillMiles <WillMiles!> has joined #yocto15:19
mcfriskrburton: thanks, I'll have a look at the patches in thud or master branch15:20
* Piraty curses Xilinx15:21
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC15:33
*** AndersD <AndersD!> has joined #yocto15:35
*** cvasilak <cvasilak!~cvasilak@2a02:587:810c:1400:8882:b774:41a5:e008> has quit IRC15:36
*** armpit <armpit!~armpit@2601:202:4180:c33:a87f:9f1d:bbdb:3483> has quit IRC15:59
*** quandtum <quandtum!~quandtum@> has joined #yocto16:04
*** yann <yann!~yann@> has quit IRC16:16
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto16:21
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC16:37
*** varjag <varjag!> has left #yocto16:38
*** tprrt <tprrt!~tprrt@> has quit IRC16:38
CroftonPiraty, would did they do this time?16:51
*** lusus <lusus!~lusus@> has quit IRC16:58
*** vmeson <vmeson!> has quit IRC16:58
*** AndersD <AndersD!> has joined #yocto17:00
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto17:00
*** AndersD_ <AndersD_!> has joined #yocto17:01
*** AndersD_ <AndersD_!> has quit IRC17:03
*** AndersD <AndersD!> has quit IRC17:04
blitz00mcfrisk: 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 install17:07
*** blitz00 <blitz00!c1f0f176@gateway/web/freenode/ip.> has quit IRC17:08
*** vineela <vineela!vtummala@nat/intel/x-hkowxjnpiroackiy> has joined #yocto17:14
yoctiNew news from stackoverflow: How to do a clean rebuild of Linux kernel modules in Yocto? <>17:21
*** vmeson <vmeson!> has joined #yocto17:22
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:23
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto17:30
*** dreyna <dreyna!> has quit IRC18:19
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:26
*** armpit <armpit!~armpit@> has joined #yocto18:52
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has quit IRC19:06
*** rcw <rcw!~rcw@> has joined #yocto19:07
*** georgem <georgem!~georgem@> has quit IRC19:13
*** georgem <georgem!~georgem@> has joined #yocto19:18
*** vmeson <vmeson!> has quit IRC19:23
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC19:31
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto19:34
*** justanotherboy <justanotherboy!~justanoth@> has joined #yocto19:41
*** Bunio_FH <Bunio_FH!> has joined #yocto19:46
*** Bunio_FH <Bunio_FH!> has quit IRC19:47
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has joined #yocto19:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:06
*** tgraydon <tgraydon!~textual@> has joined #yocto20:13
*** Saur <Saur!pkj@nat/axis/x-fqceadhxpzzkgqmv> has quit IRC20:30
*** tgraydon <tgraydon!~textual@> has quit IRC20:30
*** Saur <Saur!pkj@nat/axis/x-iylaweugsrttafna> has joined #yocto20:31
*** tgraydon <tgraydon!textual@nat/intel/x-rchbvjulchrchqfq> has joined #yocto20:31
*** armpit <armpit!~armpit@> has quit IRC20:42
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has joined #yocto20:58
*** rcw <rcw!~rcw@> has quit IRC21:05
*** JaMa <JaMa!> has quit IRC21:10
*** tlwoerner_ <tlwoerner_!~trevor@unaffiliated/tlwoerner> has quit IRC21:12
*** WillMiles <WillMiles!> has quit IRC21:13
*** justanotherboy <justanotherboy!~justanoth@> has quit IRC21:18
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto21:30
*** vineela <vineela!vtummala@nat/intel/x-hkowxjnpiroackiy> has quit IRC21:59
*** tgraydon <tgraydon!textual@nat/intel/x-rchbvjulchrchqfq> has quit IRC22:01
*** vineela <vineela!vtummala@nat/intel/x-xwsojggejsfhwbbz> has joined #yocto22:07
*** erakis <erakis!~erakis@> has quit IRC22:19
*** fatalhalt <fatalhalt!> has joined #yocto22:19
*** agust <agust!> has quit IRC22:26
*** tgraydon <tgraydon!textual@nat/intel/x-tzcpskqmkcymltkw> has joined #yocto22:29
*** fitzsim <fitzsim!> has joined #yocto22:30
*** armpit <armpit!~armpit@2601:202:4180:c33:c9c3:61ea:6899:785c> has joined #yocto22:38
*** scottrif <scottrif!~scottrif@> has joined #yocto22:50
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC23:00
*** JaMa <JaMa!> has joined #yocto23:02
*** vineela <vineela!vtummala@nat/intel/x-xwsojggejsfhwbbz> has quit IRC23:05
*** vineela <vineela!~vtummala@> has joined #yocto23:08
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:26
*** scottrif <scottrif!~scottrif@> has left #yocto23:36
*** rburton <rburton!> has quit IRC23:47
*** vineela <vineela!~vtummala@> has quit IRC23:56

Generated by 2.11.0 by Marius Gedminas - find it at!