**** BEGIN LOGGING AT Thu Aug 03 03:00:02 2017 Aug 03 07:32:02 morning all Aug 03 07:53:11 hi, any idea why I can't setup layer specific, but common to all layers, .inc files which define variables specific to recipes in the layer. Including this file in layer.conf of each layer works only for a single layer. If same file name is included in another layer, it fails, and if it is not included, the inclusion happens on only one layer, seems like first one found. Aug 03 07:54:24 mcfrisk: not limited to this specific case, have you compared both evaluation processes with bitbake -e? Aug 03 07:54:52 mcfrisk: besides, IIRC inclusion from a different layer requires the full path Aug 03 07:57:34 if you're including it from a layer.conf it's going to be applied globally Aug 03 07:58:26 as LetoThe2nd says, the way to figure out what's going on is to look at bitbake -e (and not pipe it through grep, or you lose the history information) Aug 03 07:58:40 LetoThe2nd: I'm trying to do similar to meta/conf/distro/include/security_flags.inc and have that kind of file in all/most layers to apply some recipe specific variables which override stuff from recipes. Including that from layer.conf doesn't work correctly. Should it be included/required in local.conf instead? Aug 03 07:59:34 mcfrisk: depends. first, have a look at the very top of bitbake -e. there's the .conf inclusion tree. Aug 03 08:01:39 if layer.conf files in multiple layers include/require the same file name, that results in "WARNING: Duplicate inclusion" from bitbake. Aug 03 08:05:52 so what is the correct way store and use layer specific overrides, like SECURITY_CFLAGS_pn-dbus_powerpc = "" from meta/conf/distro/include/security_flags.inc ? Or is it really not possible, and only single override file can be applied to the whole bitbake build with multiple layers? Aug 03 08:07:43 or is it just the include/require statements which don't work, meaning the overrides can be in layer specific layer.conf but not in the .inc files. Aug 03 08:09:19 mcfrisk: you get duplicate inclusion warnings because there's no point doing that, the definitions in that file have already been included and applied Aug 03 08:10:25 mcfrisk: see meta-oe for an example of a layer adding its own security flags inc file - basically, just name it differently Aug 03 08:11:28 if you want to actually *override* what's specified in the existing security flags inc file though you should really do that from your custom distro config file (which if you don't have, you should) Aug 03 08:11:53 since that will be parsed later than all of the layer.conf files Aug 03 08:13:09 bluelightning: yea but no, the same file name in different layer has different, layer specific content. but this doesn't seem to be possible. there can only be one .inc file for everything, or I need to prefix the file name with layer name. Aug 03 08:14:06 thanks, got it now, I hope Aug 03 08:14:25 mcfrisk: you may be able to get away with using the same name, I'm not sure Aug 03 08:14:36 probably safest just to use a different one Aug 03 08:15:45 bluelightning: same include file name in different layers isn't working. including it twice produces a warning too. So, they must have different names or the content must be in a single include file. Aug 03 11:45:39 hi! i built core-image-minimal with changes in build/conf/local.conf to use systemd as init system and i built meta-toolchain but in the resulting SDK the headers for libsystemd are missing. what could i be doing wrong? Aug 03 11:46:29 meta-toolchain is pretty minimal on purpose, you want to build the sdk for core-image-minimal Aug 03 11:46:35 bitbake core-image-minimal -c populaate_sdk Aug 03 11:46:46 (fix the typo obviously) Aug 03 11:47:11 rburton: luckily bitbake will say "did you mean populate_sdk" ;) Aug 03 11:47:21 yeah, good point :) Aug 03 11:47:38 has bitbake become self aware? Aug 03 11:47:54 s/bibake/skynet/ Aug 03 11:48:02 Crofton|work: nah, just uses "sounds-like" matching if there's no match for a target or task, has done that for a while now Aug 03 11:48:11 you never noticed? Aug 03 11:48:22 if anyone fancies helping my "python 2 die die die" mission then a good first step would be writing a recipe for waf. Aug 03 11:48:27 https://wiki.yoctoproject.org/wiki/NoMorePython2 Aug 03 11:48:59 I wonder if it's about time to mark meta-toolchain as deprecated Aug 03 11:49:06 i do Aug 03 11:49:07 rburton: many thanks, i'll try that Aug 03 11:49:44 shame that wasn't simply "No More Python" Aug 03 11:49:46 rburton: here's one for you https://www.youtube.com/watch?v=8sh7gALHByc Aug 03 11:49:49 rburton: sigh... our setup script still suggests it, thats something we should really fix :( Aug 03 12:37:41 hi everyone. i've got a few questions regarding u-boot and swupdate if i may. the first one: can i, from my main system, tell u-boot to boot my update image once? and if so, how? Aug 03 13:03:45 tlwoerner, how good is rpi3 in morty (or pyro)? Aug 03 13:18:58 huh, my u-boot tries to load an .itb file when running `run sdboot`, but it doesn't know the command sdboot? Aug 03 14:04:00 can i somehow tell yocto to bundle a uImage with an initramfs so i can boot a system in u-boot from one file? Aug 03 14:09:53 What is the procedure for ironing out taskhash mismatch errors? Aug 03 14:10:43 I'm constantly getting it on our build server, but never when I manually run it (of course) Aug 03 14:21:25 Has anybody figured out a recipe to build a PXE bootable Poky core-image-minimal? The biggest problem I have is my init script to mount the rootfs is getting overwritten (or overridden?) by the core initrdscripts init-live.sh file. Aug 03 14:40:29 Taskhash mismatch ... for vsi-image.bb.do_rootfs_wicenv. Man this is pesky Aug 03 14:46:09 I'd wish bitbake could be more explicit in telling what has changed when a taskhash mismatch is encountered. Aug 03 14:57:32 sveinse: yeah.. afaik the issue is, we don't know if there's a mismatch until the task parses it. so we'd have to proactively write the basehash data for every task to disk up front, just in case we need it, which imposes a cost. there are commented lines in bitbake to dump it to assist in diagnosing it Aug 03 14:59:50 kergoth: I don't know the details, but if the taskhash is a hash of a parameter database, and it mismatches, couldn't bitbake start to show the diff of the database? Aug 03 15:00:10 kergoth: anyhow, how can I proceed dumping the database and comparing? Aug 03 15:00:37 My main problem is that manual invocation of bitbake seems to not trigger the taskhash, so its elusive... Aug 03 15:00:40 again, it has to have something to diff against Aug 03 15:00:52 * kergoth nods, usually is Aug 03 15:01:02 right, so it has the hash, but not the data? Aug 03 15:01:06 right Aug 03 15:01:10 ok Aug 03 15:01:18 probably an ordering issue somewhere. i.e. something references a list, and the list's order changes sometimes, but not always Aug 03 15:01:36 the main suspect with such things is DATE or TIME references, but a TIME reference would happen every time, not randomly.. Aug 03 15:02:03 so it's either a DATE reference across a date change (build at midnight?) or something else is changing between the up front parse and the later parse, hence the ordering possibility Aug 03 15:02:15 I've search very thorougly for DATE, I don't think it is. But still... Aug 03 15:02:31 you'll probably want to comment out the aofrementioned lines in bitbake, that'll make bitbake write out the basehashes, you should end up with two where they should only be one, and can use bitbake-diffsigs to compare Aug 03 15:02:36 i'll see if i have the patch handy Aug 03 15:05:34 sveinse: https://gist.github.com/kergoth/8b0c01b86d8ab4d9330527ba9c2bb8e2 Aug 03 15:05:43 might not apply directly, but you get the idea Aug 03 15:07:06 that'll dump basehash sigdata/siginfo into your stamps directory Aug 03 15:08:15 Perfect. And run bitbake-diffsigs without arguments? Aug 03 15:09:49 diffsigs won't do anything without arguments. it has options for recipe+task, but probably won't be useful in this context, you'll likely want to look at your stamps dir, find the case where you have two sets of basehash sigdata for the same task, and specify the paths to those two files on the bitbake-diffsigs commandline Aug 03 15:10:01 i think that's still the best bet to diagnose this, but RP might have other suggestions Aug 03 15:10:12 * kergoth hasn't had to fix one in a while Aug 03 15:10:42 Tartarus, was that the approach you took when digging into yours the other day? Aug 03 15:10:45 or did you find a better method? Aug 03 15:11:34 kergoth: I used diffsigs and had the two stamp files around Aug 03 15:11:45 * kergoth nods Aug 03 15:11:47 okay, thanks Aug 03 15:11:53 That showed me an actual difference in the same task Aug 03 15:11:59 And then I figured out a way to solve that Aug 03 15:12:32 * kergoth wonders what the actual performance impact of writing that data all the time would be Aug 03 15:13:12 Probably noticeable just because it would be a ton of small files? Aug 03 15:13:21 But enabling the dump should be easier Aug 03 15:13:49 * sveinse testing patch and starting build. Crossing fingers that this triggers the taskhash mismatch Aug 03 15:14:12 good luck :) worst case you can add the patch to your automated builds for a while and just deal with the performance impact until you get it resolved, been there, done that Aug 03 15:14:19 remember to save the stamps dir, if you do that Aug 03 15:15:36 Heh getting 2099 of "setscene failed with exit code '1' - real task will be run insted" and then it dies :( Aug 03 15:16:01 damnit irc client stop disconnecting Aug 03 15:16:13 khem: new glibc actually builds!!! Aug 03 15:17:54 sveinse: yikes. i've seen that, but very rarely.. weird Aug 03 15:19:22 hmm, is the py code correct? Aug 03 15:19:40 rburton: cool. Aug 03 15:20:05 * kergoth shrugs Aug 03 15:20:51 khem: respinning on the AB to see what happens there Aug 03 15:21:11 rburton: your local machine is wierdest Aug 03 15:21:18 AB machines are friendlier to me Aug 03 15:21:21 khem: and all the builders! Aug 03 15:21:26 they all failed with the last patch Aug 03 15:21:39 not this time, in general I mean Aug 03 15:21:53 you find more wierder issues with patches Aug 03 15:22:14 I must trick you in installing a sane distro Aug 03 15:23:09 it's debian stable! :) Aug 03 15:23:19 i'm not running something twisted like arch Aug 03 15:24:07 nooo arch is the future Aug 03 15:24:22 i scoff at your "sane distro" comment Aug 03 15:24:52 Debugging: bitbake/lib/bb/siggen.py:l177 (in krogoth), it reads for task in self.taskdeps[fn]: self.dump_sigtask(fn, task, d.getVar("STAMP", True), False), but then the line after states for task in taskdeps:. Are we sure it shall be self.taskdeps[fn] in it? Aug 03 15:25:14 Something messes up bitbake completely when this is enabled at least Aug 03 15:25:23 entirely possible that the existing lines were changed but not the commented bits Aug 03 15:25:25 * kergoth shrugs Aug 03 15:25:36 darn Aug 03 15:25:42 rburton: arch is very stable, future is rolling distros Aug 03 15:25:51 i should install arch again, been a while Aug 03 15:26:06 rburton: debian stable is better than centos certainly Aug 03 15:27:08 sveinse: i'd say yeah, try changing it to taskdeps instead and see how it goes Aug 03 15:27:14 rburton: and you must be sneaking in testing and unstable feeds I am sure Aug 03 15:29:59 rburton: I saw runtime tests were failing for musl on AB yesterday Aug 03 15:30:19 rburton: it wasnt due to musl change btw. since it was failing without musl patch Aug 03 15:30:43 Same result. Failed. Aug 03 15:32:04 heh, by timeframe of this test, I had 4 guys and 1 boss in my office asking when the build is up and running again. Somebody is (of course) expecting a beta build for testing today :( Aug 03 15:32:53 figures Aug 03 15:35:05 So, how to get the build server to generate a sigdata for me to compare and find the altered parameter Aug 03 15:35:29 (thumbs up for arch! :) ) Aug 03 15:36:01 One way to fix the issue is to disable sstate altogether I suppose. But that'll take a million years to compile Aug 03 15:36:33 Yet that is less than what I would take me if I cant figure it out Aug 03 15:43:50 bitbake-diffsigs can diff on bitbake -e files? Aug 03 15:44:33 no, diffsigs diffs signature data, which relies on variable tracking and analysis Aug 03 15:44:36 doesn't compare metadata Aug 03 15:44:56 Can I dump the sigdata from bitbake cmd line? Aug 03 15:46:41 that's what bitbake-dumpsigs is for Aug 03 15:46:46 dumpsig, whichever Aug 03 15:50:47 I must be slow, but where do I find or generate the siginfo/sigdata files bitbake-dumpsig requires? Aug 03 15:59:24 oh, right, misunderstood your question Aug 03 15:59:33 the way you get them written is hte patch i gave you, except it apparnetly needs to be fixed Aug 03 15:59:55 right. ok, thanks for trying Aug 03 16:02:20 But I have to hand it to you guys, the taskhash collision resolution gotta be resolved in a much better way. Performance or not. It is way too cumbersome to debug and extremely costly. Aug 03 16:04:50 Perhaps an article to write for the TipsAndTricks wiki? Aug 03 16:05:28 should probably add a bitbake argument to collect and write the additional data needed to diagnose, and ideally also have bitbake automatically use that data to dump the delta on hitting a taskhash mismatch? Aug 03 16:05:44 if you would, open a bugzilla bug to improve the workflow for diagnosing taskhash mismatches, if one doesn't already exist Aug 03 16:08:22 for bitbake, right? Aug 03 16:08:53 yeah Aug 03 16:08:58 thanks Aug 03 16:09:18 Tartarus may have a working version of those lines in bitbake to dump the basehashes, i don't have it handy Aug 03 16:09:48 What you pasted above should still apply Aug 03 16:09:56 Or be a trivial fixup Aug 03 16:10:08 I think things have shifted like 5 lines, but context is fine Aug 03 16:10:31 I edited the file myself, not use the patch Aug 03 16:11:27 Why I get failures in setscene I don't know Aug 03 16:13:20 Hmm, what should I ask for in the bugzilla bug? The concept of taskhash being too hard to diagnose, or that the patch does not work? Aug 03 16:13:45 the former, we need to improve the workflow for diagnosing taskhash mismatches Aug 03 16:13:54 My concern is mostly the former. The others are just methods for doing that Aug 03 16:19:05 right Aug 03 16:19:20 and not a very pleasant method, at that, just better than nothing :) Aug 03 16:26:41 All right, sticking my head out: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11892 Aug 03 16:26:42 Bug 11892: enhancement, Undecided, ---, richard.purdie, NEW , Missing workflow for identifying taskhash workflow Aug 03 16:27:17 thanks, appreciate it Aug 03 16:27:30 dealing with those is a long standing annoyance Aug 03 16:27:38 well, thank you for trying your best to assist Aug 03 16:27:51 I'm no closer to a resolution to our broken build thou :( Aug 03 16:38:29 sveinse: reload the gist patch link i gave you, now it applies and i verified it works Aug 03 16:39:10 erm, no, hold Aug 03 16:39:27 there, now it's there Aug 03 16:39:56 then do your build and examine the *sigbasedata* files in tmp*/stamps/ Aug 03 16:42:41 no idea why yours failed, as this is basically the same thing Aug 03 16:42:42 built fine here Aug 03 16:42:44 * kergoth shrugs Aug 03 18:26:07 this is odd, i'm seeing a situation where the import of modules in the oe namespace package from layers other than oe-core can't be imported when using devtool, but works just fine running bitbake directly Aug 03 18:26:14 like the sys.path changes aren't taking effect or something Aug 03 18:27:10 does vevtool filter out anything before invoking bitbake proper ? Aug 03 18:33:42 wouldn't expect so, should be just using tinfoil, server should start as it always does..hmm Aug 03 18:35:05 huh, didn't know about https://www.python.org/dev/peps/pep-0420/ Aug 03 18:37:08 oddly, recipetool newappend works fine, but devtool modify doesn't, parsing the same metadata Aug 03 19:21:09 hello! Aug 03 19:24:54 i'm having some layer issues? like if a layer fails to build and i suspect it's more the layer's fault than mine. i'm not sure how to debug a layer or how to report the issue, to whom, etc Aug 03 19:25:54 identify which recipe it is, file bug as per instructions in layer reade Aug 03 19:26:50 rburton, ok, fair. straightforward lol Aug 03 19:39:46 Hello - is there an "image" format that would essentially be a zip file of the contents of the hddimg file? Aug 03 19:55:35 Circuitsoft: zip? that would be unlikely to be useful. tar.gz, yes. Aug 03 19:56:20 In my case, I don't care what the archive format is, because the hddimg is fat, not ext. Aug 03 19:56:39 I was thinking of trying to go cpio/xz due to ease of file format extraction, but I can deal with anything. Aug 03 20:54:31 kergoth: I did try writing the sigdata all the time. Its a *huge* amount of IO sadly Aug 03 20:54:57 kergoth: If we had some kind of compressed data store it might be possible but that was more work than I had time for Aug 03 21:11:50 a wiki (section 4.5.3 here: http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_MORTY_V1.0_DART-6UL#Use_systemd_instead_of_SysV_init) speaks of appending some stuff to the conf/local.conf file in the "yocto build directory", but the neither yocto build directory nor the conf/local.conf file exist yet. Aug 03 21:12:11 that is, after the initial repo init/repo sync steps Aug 03 21:12:25 so do you have to build a target first, then modify and rebuild? Aug 03 21:13:56 s/target/image Aug 03 21:16:04 no. i see now. just do the setup-environment Aug 03 21:25:18 is there a way to check if the setup-environment has already been run? for exmaple, by checking a specific environment variable? i seem to often cd out of the build directory and later can't remember if i've setup the environment or not Aug 03 21:27:51 echo $MACHINE doesn't seem to work. Aug 03 21:29:20 is this thing on? Aug 03 21:29:42 * yates tests the microphone... Aug 03 21:29:44 yates: Running oe-init-build-environment again doesn't hurt anything. Aug 03 21:32:48 There are also variables like BUILDDIR and BB_ENV_EXTRAWHITE Aug 03 21:33:00 but BUILDDIR seems to be the most reliable one. Aug 03 21:36:17 is there a shell that will work with yocto/bitbake? https://da.gd/bcgQ -> https://paste.fedoraproject.org/paste/dfvRMS5ljyUYaM60DpgS8w/ Aug 03 21:36:22 an emacs shell, that is? Aug 03 21:47:57 todor, Can you help with eclipse-poky issues? Or point me at someone. Aug 03 21:48:18 moto-timo: ^^ ?? Aug 03 21:49:08 Oh moto-timo is here. I was looking for ticotimo. Aug 03 21:50:09 Thank you joshuagl. :) Aug 03 21:50:45 :-) Aug 03 21:57:35 moto-timo, joshuagl, It's an issue with the downloads server now being behind the same NAT as the .io workers. When I test from the command line it works over IPv6 but the script here is forcing IPv4 and that isn't working. I think I can fix this. Aug 03 21:57:52 halstead: brilliant, thanks! Aug 03 21:59:16 once you have setup a build directory the first time via MACHINE=foo DISTRO=bar . setup-environment build_xyz, can you just (in a new terminal/shell) run setup-environment build_xyz? Aug 03 22:01:14 or rather ". setup-environment build_xyz"? Aug 03 22:13:15 halstead: I'm calling it a day, could you let me know how it goes? Aug 03 22:13:27 joshuagl, I just started Aug 03 22:13:38 joshuagl, And it's working with split DNS now. Aug 03 22:13:52 started a test that is. Aug 03 22:13:53 halstead: awesome Aug 03 22:13:59 * joshuagl nods Aug 03 22:15:09 joshuagl, I'll get them moved to different subnets later so it won't crop back up. Thanks again. Have a good night. Aug 03 22:15:27 thank you halstead! Aug 03 22:15:29 * joshuagl waves **** ENDING LOGGING AT Fri Aug 04 03:00:00 2017