**** BEGIN LOGGING AT Wed Mar 22 03:00:02 2017 Mar 22 07:34:21 bluelightning: around? Mar 22 08:03:00 pohly: I am now yes Mar 22 08:03:17 I am trying to use the tinfoil API. Mar 22 08:04:26 I'm a bit puzzled by event handling. I had it working yesterday such that I get plenty of events, including the bb.event.DepTreeGenerated that I trigger with tinfoil.run_command('generateDepTreeEvent', args[1:], 'do_build') Mar 22 08:04:52 What I did not have working yesterday is a progress bar for cache loading (I only got the events). Mar 22 08:05:39 Today, it's the other way around, and I am not sure what I changed: I get the usual progress bar during tinfoil.prepare(config_only=False), but then only very few events from wait_event(). Mar 22 08:12:36 morning Mar 22 08:17:52 morning Mar 22 08:18:06 (of course it's after 4pm here) ;) Mar 22 08:20:19 * RP doesn't like the look of the selftest failures in the last build :( Mar 22 08:29:06 and the selftest failure is caused by corruption of opkg-native with systemd enabled/disabled :/ Mar 22 08:30:42 good morning Mar 22 09:18:40 RP: let me know if you want me to do something WRT the selftest failure on master-next: I can see sed+xargs+sed fails ... but don't really understand it Mar 22 09:26:18 jku: Its hiding the real error which is sed: can't read /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/lib/systemd/system/opkg-configure.service: No such file or directory Mar 22 09:26:35 jku: I think I know what might have caused this (approximately) Mar 22 09:27:00 kanavin: I agree with your datestamp theory on the signing issue btw Mar 22 09:27:10 kanavin: didn't reproduce yesterday here, it does now :) Mar 22 09:27:41 I'm using a setup made by others. I have built a lot of packages with a wrong MACHINE value, and since they don't use rm_work, I have lot of wasted space. What's the good way to clean that up? I remember once I removed stuff manually and bitbake complained about wrong sstate. Mar 22 09:37:41 jku: Steps to reproduce are bitbake opkg-native; bitbake opkg-native; ; bitbake opkg-native; bitbake opkg-native; then try and build an image Mar 22 09:38:22 RP: rburton above has a link where the build didn't cross days and still seems to fail Mar 22 09:39:05 but I honestly don't know what else could it be Mar 22 09:39:11 kanavin: if it reused sstate from an earlier build it still breaks (I just proved that) Mar 22 09:39:54 RP: can you tell if sstate is reused here https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/850/steps/Running%20oe-selftest/logs/stdio - it seems to me it's not but maybe I'm not reading the log correctly Mar 22 09:40:51 kanavin: which packages does /etc/pki/rpm-gpg/RPM-GPG-KEY* live in? Mar 22 09:40:56 well, recipe Mar 22 09:41:02 signing-keys, I believe Mar 22 09:41:48 kanavin: that the logs say it did build that package specifically Mar 22 09:41:53 er, recipe Mar 22 09:42:19 RP: in any case having DISTRO_VERSION in the key name does not make sense to begin with, I'll make a patch that fixes that Mar 22 09:42:28 RP: then we'll see if the issue still shows up Mar 22 10:02:14 jku: root caused it, its a nasty sstate bug :/ Mar 22 10:03:42 jku: I do have a problem you could look into though - why does opkg-native have systemd units when systemd is in DISTRO_FEATURES - does changing DISTRO_FEATURES really mean we have to rebuild opkg-native ? Mar 22 10:04:18 jku: I'm wondering about a DISTRO_FEATURES_class-native = "XXX", forcing it to a set of known values Mar 22 10:07:07 building slang fails over here due to qa issues. "ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities." Mar 22 10:07:18 is that a known issue? Mar 22 10:08:05 T_UNIX: we've seen that at various points. Which release are you using? Mar 22 10:08:32 RP: morty Mar 22 10:09:46 T_UNIX: you could try some of the recent changes: http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=slang Mar 22 10:10:23 will do Mar 22 10:10:29 RP: thanks :) Mar 22 10:10:42 T_UNIX: Ross changed it quite a bit in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9a1ac06139591f70a72cd915059a5705d856a1ee for problems like this amongst other reasons Mar 22 10:18:29 yeah. It seems that patch fixes it. Though I was too lazy and cherry-picked all three patches (2 version updates + that rewrite patch) because picking that single commit didn't apply cleanly :-D Mar 22 10:22:51 T_UNIX: right, a bit harder to do that on the stable branch :/ Mar 22 11:13:54 RP: I'll have a look Mar 22 11:14:22 jku: thanks Mar 22 11:14:45 jku: its clear from do_install what is happening and I've fixed the sstate breakage but it raises further questions Mar 22 11:15:00 jku: we either need to come up with a fix or document it in bugzilla Mar 22 11:23:04 RP, bluelightning: I'm getting an odd pn name from bb.event.DepTreeGenerated: multiconfig:qemuarm.glibc instead of multiconfig:qemuarm:glibc Mar 22 11:24:17 bluelightning: and tinfoil.parse_recipe('multiconfig:qemuarm.glibc') fails (but also does for multiconfig:qemuarm:glibc) - it seems to not find a fn for it with self.get_recipe_file(). Mar 22 11:24:56 tinfoil.parse_recipe_file() works for me, with the filename contained in the dep graph. Mar 22 11:26:14 pohly: sounds like a bug Mar 22 11:26:33 should be a : in there, not a . Mar 22 11:26:52 pohly: I may have taken some shortcuts that mean that the multiconfig prefixes don't work there, but they ought to I think Mar 22 11:27:31 RP: I'll have a look and fix it if I can, otherwise I'll file a bug. Mar 22 11:27:43 pohly: thanks. Hopefully its something simple Mar 22 11:28:11 RP: probably. However, for the tinfoil problem I have no idea where to look, so I'll probably just file a bug. Mar 22 11:33:07 when I built core-image-full-cmdline it fails at do_populate_sdk, which is werid as I think it shouldn't even try to do that. I guess I can see why it fails, because my toolchain is set to be built for mingw, but i'm in linux Mar 22 11:37:02 yourfate: by default "bitbake core-image-full-cmdline" would not run populate_sdk so you must have some change adding a dependency Mar 22 11:42:38 RP, that's what I thought. I have TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc" in my local.conf, could that be it? Mar 22 11:56:57 hello Mar 22 11:57:14 RP: well I was refereing to the delta of morty and`git log master -- meta/recipes-extended/slang/` Mar 22 11:57:29 i am updating systemd from v225 to v232 in our repo Mar 22 11:58:08 i don't understand why, one patch which should be already in, according to git log, is still applying Mar 22 11:58:25 and the log is not very explicit about the patching Mar 22 11:58:34 a mistake? Mar 22 11:59:20 rburton, i'll look at the source Mar 22 11:59:39 what may happen is that the fix was reverted, or just modified Mar 22 11:59:45 in upstream, that is Mar 22 11:59:53 cornel: also patching is still done with very minimal context matching (there's a bugzilla ticket). So unfortunately patches may apply when they shouldn't Mar 22 12:00:06 jku, i see .... Mar 22 12:00:08 pfff Mar 22 12:00:17 cornel: so you just need to check Mar 22 12:00:24 jku, do you have the ticket id? Mar 22 12:01:11 cornel https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 Mar 22 12:01:12 Bug 10450: normal, Medium+, 2.3 M4, alexander.kanavin, IN PROGRESS DESIGN , Reduce fuzz factor when patching files Mar 22 12:01:23 thank you very much Mar 22 12:04:04 cornel: that bug is stalled, pending devtool improvements which Paul Eggleton hasn't yet gotten to Mar 22 12:04:23 thank you kanavin Mar 22 12:04:31 cornel: I recommend you poke him :) Mar 22 12:04:46 :) Mar 22 12:04:53 (the link to the devtool improvement bug is in 10450, so write a comment Mar 22 12:05:38 the problem with fixing this is that if we tighten up the patching, we'll break all layers, badly Mar 22 12:05:48 eh Mar 22 12:05:52 so we first need to have tooling support in place to ease the unbreaking Mar 22 12:06:14 but if it's not fixed, we're in a different kinf of mess, where we believe things are right but they may actually be not Mar 22 12:06:20 (which basically means rebasing all patches that no longer apply) Mar 22 12:06:46 cornel: yes, it's a serious problem - read how I found out about it, and what kind of security implications it would have Mar 22 12:06:52 (in 10450) Mar 22 12:08:32 cornel: if you want to try out the stricter patching, cherry-pick this commit: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/fix-patch-fuzz&id=827172d096dd62648506c0341d0207bd6353203d Mar 22 12:09:06 kanavin, thank you Mar 22 12:09:06 then your systemd patch should trigger an error Mar 22 12:12:12 I removed the toolchain task, now it fails with the following error: i.reddituploads.com) Mar 22 12:12:14 submitted 11 hours ago by cronus999 Mar 22 12:12:16 oops Mar 22 12:13:23 does bitbake-selftest leave a log somewhere? Mar 22 12:13:41 so i've checked the source, the patch is applied even if the fix was already there Mar 22 12:14:06 hooray patch Mar 22 12:14:14 patches can be written that re-apply Mar 22 12:14:30 this has no effect if 'if' returns true Mar 22 12:15:24 i wonder what happens if that 'if' condition fails :) Mar 22 12:15:49 cp: target '/home/widmann/yocto/poky/build/tmp/work/zybo_linux_bd_zynq7-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/rpms/zybo_linux_bd_zynq7' is not a directory Mar 22 12:15:51 is the error Mar 22 12:17:36 ok, if the condition fails, it fails two times :) Mar 22 12:17:50 spo this particular patch has no side effect Mar 22 12:18:18 cornel: patch please :) Mar 22 12:19:33 rburton, eh, this was our local patch backported from upstream, so i assume is irrelevant to the big upstream poky Mar 22 12:20:09 but let me check Mar 22 12:20:17 ah, hope so Mar 22 12:20:18 thanks Mar 22 12:20:31 confirmed Mar 22 12:20:36 upstream is not affected Mar 22 12:20:45 phew Mar 22 12:20:57 in their version of systemd v232 patch 0001-execute* is not applied separately Mar 22 12:21:26 but the commit is in the systemd v232 log Mar 22 12:21:50 which as it should be Mar 22 12:22:32 1ff74fb6e324 Mar 22 12:30:56 rburton: the debug output in https://autobuilder.yoctoproject.org/main/builders/nightly/builds/1193/steps/BitbakeSelftest/logs/stdio -- how do I see that locally? Mar 22 12:31:46 hm Mar 22 12:32:12 jku: -v? Mar 22 12:32:26 or dig around in tmp/log/ Mar 22 12:32:38 no, -v only lists tests Mar 22 12:32:57 hm Mar 22 12:33:48 rburton: so "watching logfiles {}" means you get some log file changes included on the AB output? Mar 22 12:36:40 pass Mar 22 12:36:47 ask joshuagl Mar 22 12:46:03 rburton: you're right, the signing failures were not about the wrong date Mar 22 12:47:05 kanavin, patch appied, test in progress Mar 22 12:47:37 cornel: expect an explosion of patch failures if you're testing more than just patching systemd Mar 22 12:47:50 :) Mar 22 12:47:58 that6's exactly what i expect Mar 22 12:48:09 i'm doing a full project build, not just systemd Mar 22 12:48:35 cornel: I think oe-core alone has on the order of 80 failures - we started to fix those, then realized we really need a tool for it Mar 22 12:48:37 here we go Mar 22 12:48:49 0026-eglibc* fails Mar 22 12:50:12 in poky (jethro) Mar 22 12:50:39 cornel: you probably should do a '-c patch -f' to patch everything at once Mar 22 12:51:37 kanavin, you mean change your patch? Mar 22 12:52:30 cornel: no, if you want to patch all of the recipes at once, and see which of them fail Mar 22 12:52:38 ah Mar 22 12:52:45 'bitbake -c patch -k -f' Mar 22 12:52:55 as bitbake arguments ... Mar 22 12:52:58 thank you Mar 22 12:53:00 gonna try Mar 22 12:59:09 it crashed immediately after one automake patch Mar 22 13:02:18 jku: rburton: I think bitbake just detects that it's a non-interactive session and displays knotty output differently Mar 22 13:03:02 joshuagl: so ... any hints? Mar 22 13:04:41 try selftest | cat to test josh's theory Mar 22 13:07:46 itym bitbake-selftest | cat` Mar 22 13:08:04 doesn't seem to change anything Mar 22 13:08:40 I don't think there are any log files either Mar 22 13:13:51 hmm, I think we can set BBDEBUG in the environment but I don't see evidence of the AB doing that Mar 22 13:28:44 jku: that output is bitbake traceback information, only dumped upon error Mar 22 13:28:51 jku: hack the test to fail? Mar 22 13:29:23 jku: hacking your local DNS to fail to resolve a name would likely do it Mar 22 13:29:33 jku: I suspect that failure was a transient network issue Mar 22 13:29:57 joshuagl: there is something seriously slow about linux-yocto fetches on both ABs :( Mar 22 13:30:06 joshuagl: both ABs are blocked with that atm :( Mar 22 13:31:19 thanks, it was so long I thought it wasn't just context for the failure but that does make sense Mar 22 13:32:17 RP: OK, will try and get together with halstead and figure it out Mar 22 13:34:29 joshuagl: I'd try a manual clone onto the nfs, I think that is the issue Mar 22 13:36:39 joshuagl: actually, it looks hung on locks :( Mar 22 13:40:21 :-( Mar 22 13:40:40 not sure why we clone on NFS, istr we discussed not doing that already. Mar 22 13:40:59 ah, probably the initial clones of the layer repos Mar 22 13:43:02 joshuagl: ah, one of the Mar 22 13:43:15 joshuagl: I can't even see where one of the running clones was triggered from :/ Mar 22 13:44:41 joshuagl: ah, somehow I managed to run the same build twice :/ Mar 22 13:48:05 RP: all too easily done, I'm afraid :-/ Mar 22 13:48:15 RP: so the two builds are interfering with each other? Mar 22 13:53:02 joshuagl: the two builds are blocked on oe-selftest which is actually running the fetch Mar 22 13:54:44 oh, selftest clones the kernel? Mar 22 13:54:53 joshuagl: one of the tests must Mar 22 13:56:37 kernel-devsrc is listed as a recipe to test in test_devtool_modify_invalid Mar 22 13:57:18 RP: any idea how I can increase the debug level for bb.debug() output messages from a tinfoil client? Mar 22 14:06:43 pohly: increase the logging client or server side? Mar 22 14:06:56 pohly: I'm not sure there is tinfoil API to change server side right now :( Mar 22 14:07:47 Only changing the log level on the client side isn't enough. I suspect I need help from bluelightning. Mar 22 14:09:53 pohly: I suspect so too unfortunately. I'm pretty sure we're find with adding a command it one doesn't already exist Mar 22 14:10:02 pohly: but I don't know if its currently possible or not Mar 22 14:17:54 is it possible to use regular expressions to install packages into a image? something like IMAGE_INSTALL += "perl-module-*"... Mar 22 14:23:25 adca: no, but often there are packages for "all perl modules" Mar 22 14:23:31 or "all kernel modules" Mar 22 14:24:01 RP: thanks! Mar 22 14:34:07 I was trying to add some layers via bitbake-layers add-layer .. and after adding some of them, I’m now getting a layer parse error. I can’t get anything useful out of the error message and stack trace. Anyone have a tip on how to debug the layer.conf that is causing a problem ? I guess I can start nuking lines from it. Mar 22 14:41:01 zeddii_home: pastebin it? Mar 22 14:41:02 zeddii_home: would be nice to figure out the issue and improve the failure message... Mar 22 14:41:11 this has failed my 10 minutes of effort test Mar 22 14:41:22 back to writing up echo “foo” instructions Mar 22 14:42:10 zeddii_home: :( Mar 22 14:42:28 zeddii_home: when you do figure it out, a reproducer in bugzilla would be much appreciated Mar 22 14:42:47 zeddii_home: I'd probably bisect the entries in BBLAYERS by hand Mar 22 14:43:14 whenever I add either meta-networking or meta-virtualization via bblayers, I can never add any more. layer parse error after that. Mar 22 14:43:19 since I can push to meta-virt, I thought I’d fix it. Mar 22 14:43:30 but I compared it line by line to one that worked, and can’t for the life of me see the crime. Mar 22 14:44:46 oh. intersting. Mar 22 14:44:50 zeddii_home: if you pastebin the trace I can look at it... Mar 22 14:44:53 it may just be a missing depdency. Mar 22 14:45:31 i.e. I just manually put meta-networking into the bblayers var, and I could add meta-virt + meta-security. I did track it down to the depends line, but the error message didn’t scream out “you idiot, you are missing a dependency” Mar 22 14:45:54 we need to get better at how we handle this :/ Mar 22 14:45:54 lol Mar 22 14:46:00 confirmed. Mar 22 14:46:05 I’ll pastebin the steps. Mar 22 14:46:13 * Crofton|work recalls how much pain RP had fixin fthe missin gMCHINE var message :) Mar 22 14:46:24 but if I remove meta-networking, and then bitbake-layers add-layer ../meta-virtualization/ Mar 22 14:46:31 and bitbake-layers add-layer ../meta-security/ Mar 22 14:46:34 it backtraces Mar 22 14:46:38 zeddii_home: bugzilla entry would be ideal Mar 22 14:47:02 http://pastebin.com/FRRZ8AGG Mar 22 14:47:04 yep. will do. Mar 22 14:47:10 zeddii_home: if it helps, it took me 3 days to work out that an oe-selftest was failing on centos7 as it was using git add without -A Mar 22 14:47:28 it only pointed me at BBFILE_COLLECTIONS in the trace, so I was off looking at that variable Mar 22 14:47:37 (git versions pre and post 2.0 behaving differently) Mar 22 14:47:44 I’ll put it all in a bugzilla, and can avoid writing up instructions that avoid echo Mar 22 14:48:02 RP: yuck. I feel the pain, having had to support multiple git versions in tools in the past. Mar 22 14:48:10 'file' was changed again? Mar 22 14:48:24 cornel: they fixed things to how they were before Mar 22 14:48:24 file can burn in hell Mar 22 14:48:47 RP, thank you very much Mar 22 14:48:53 Crofton|work, :) Mar 22 14:49:09 Crofton|work: I think you should say what you really feel, stop holding back ;-) Mar 22 14:49:22 :D Mar 22 14:49:38 RP, do you happen to know if this is true also foe FILE5_24 ? Mar 22 14:49:44 Heh, email thread with customer who is using jethro yesterday, and I delayed reading oe list until later in the day Mar 22 14:49:50 So yes, I am bitter Mar 22 14:49:50 cornel: yes, they reverted everything Mar 22 14:49:58 RP, thank you Mar 22 14:50:11 * cornel goes to revert commits .... Mar 22 14:50:12 is anyone taking patches for jethro? Mar 22 14:50:34 Crofton|work: I'd have fixed this in jethro but we never got to it, so no need to revert there Mar 22 14:50:53 well, I think it is broken there Mar 22 14:51:19 hashes changed, tight? Mar 22 14:53:23 Crofton|work: yes, but upstream put the old ones back now Mar 22 14:57:43 wow, i'm seeing a bizarre behaviour that's driving me nuts, maybe zeddii_home can provide some insight? Mar 22 14:58:30 i'm building a kernel with CONFIG_LOCALVERSION_AUTO enabled, and the "touch .scmversion" thing removed because i want "uname -a" to give the full kernel version including git sha Mar 22 14:59:21 if i build like normal and look in packages-split, all the modules etc have "-dirty" appended, even though cd'ing to the kernel source directory and doing "git status" shows nothing to commit, no changes Mar 22 14:59:37 fun fact: we have ~80 distro features in oe-core. That makes a lovely test matrix Mar 22 14:59:43 (almost half are libc-* features though) Mar 22 14:59:50 if i build the kernel with "-j 1", it takes a long time, but the directories in packages-split don't have "-dirty" Mar 22 15:00:17 but when I run that image, "uname -a" still appends "-dirty" to the version Mar 22 15:00:17 tlwoerner: do you know if perf is being built ? not sure about the -j1 thing yet .. Mar 22 15:00:40 I have to step out for lunch in 15 mins, but can ponder it more this afternoon. Mar 22 15:01:18 zeddii_home: i don't know if perf is being built... okay :-) Mar 22 15:01:21 the reason I ask about perf is that we have to mangle (sed) the source files, and they aren’t checked in. so you will get -dirty. Mar 22 15:01:43 I have an open bug to deal with it, but there’s no easy solution. or I should say one that doesn’t involve forked repos or lots of i/o Mar 22 15:02:02 so check on perf. it may be part of the problem. or not. and that was just FYI. Mar 22 15:02:28 I can also spin up a build with your .scmversion patch applied and see fi the same thing happens. Mar 22 15:02:56 zeddii_home: oh cool, you've seen my patch :-) Mar 22 15:03:22 zeddii_home: i'll send you my recipe too (by email?) Mar 22 15:03:32 yah. that would help. Mar 22 15:05:30 ok great :-) i'll rejig it for qemux86 too (currently i'm focused on minnow and firefly) and email it Mar 22 15:06:03 RP, so jethro was broken and is now fixed (for the file fetch hash) Mar 22 15:06:36 Crofton|work: yes Mar 22 15:06:56 (making sure history is clear for people that find this) Mar 22 15:13:38 in 'file' , the FILE5_24 tag still points to the modifed commiit, which also exists Mar 22 15:20:09 cornel: but the original is still on the master branch so we're good Mar 22 15:23:09 should probably report it if the tags are still pointing to the modified commits, though, even if it doesn't break us Mar 22 15:23:10 * kergoth yawns Mar 22 15:30:21 hmm, i wonder why the gitsm fetcher is manually parsing git config files instead of just using git config Mar 22 15:31:37 Hi guys, Mar 22 15:32:08 I'm new to Yocto, I'm studying it since 2 weeks and I'm doing my internship about it. Mar 22 15:32:26 I'm building a raspberry pi distro. Mar 22 15:32:47 I've a simple quesiton, how can I add a simple C application on my distro ? Mar 22 15:33:21 Do I have to make a new receipe or is there simple effective way to do that? Does some one ever did a script to add a C program to yocto ? Mar 22 15:34:03 YCN-: simplest is just a new recipe to build it Mar 22 15:34:04 basically, you need a recipe Mar 22 15:35:05 Okay thanks :), Imma try to build a script based on sources in order to auto-create a recipe. Mar 22 15:35:25 If I do end up with a good solution I'll share it ! Mar 22 15:36:09 Thanks guys Mar 22 15:40:59 is there easy way to override default oe-core/meta/lib/oe/rootfs.py? Mar 22 15:44:22 JaMa: I worry a bit that you'd need to do that :/ Mar 22 15:44:40 JaMa: you probably could hack the module search paths to get an alternative version seen first Mar 22 15:45:14 JaMa: generally you can override any such module by appropriately ordering your layer in BBLAYERS and copying the __init__.py (which uses namespace packages), iirc Mar 22 15:45:26 we already include layer paths in the python module search path Mar 22 15:45:30 in bbpath order, iirc Mar 22 15:46:19 that said, i haven't had my coffee yet, so take anything i say with a grain of salt :P Mar 22 15:47:04 kergoth: I'd not try that with the coffee though :) Mar 22 15:47:36 oh yeah, it's a terrible idea to do it in general, but i've had to do it before when we were close to release and couldn't risk updating the upstream layers, but needed a bugfix in an oe module Mar 22 15:48:02 kergoth: I meant the grain of salt with the coffee Mar 22 15:48:18 kergoth: I'd ignore me, selftest is doing bad things to my brain :( Mar 22 15:48:22 oh, actually alton brown says adding a tiny amount of salt counteracts bitterness better than sugar Mar 22 15:48:25 i haven't tried it yet, though :) Mar 22 15:48:32 http://altonbrown.com/how-to-brew-best-cup-of-coffee-at-home/ Mar 22 15:48:47 "Salt and Coffee: Not only does salt cut the bitterness of coffee, but it also smooths out the “stale” taste of tank-stored water. I’ve taken to adding a quarter teaspoon of kosher salt to every 6 tablespoons of grounds. That isn’t really enough to taste, but it’ll do the trick. And by the way, research has proven that salt is actually better at neutralizing bitterness than sugar." Mar 22 15:48:53 quite interesting Mar 22 15:49:12 kergoth: that is interesting Mar 22 15:50:04 if I wanted yocto to include custom files in the core-image-full-cmdlilne, like my uEnv.txt and my etc/network/interfaces config, how would I do that? Mar 22 15:50:33 I started mulling over how to make gitsm suck less, and i was thinking about using the fetcher for the submodules.. but if we do that, we have to make assumptions about how modules are stored in the repository.. maybe not critical, we can fix it as upstream changes, but then I was thinking another possibility would be to write a custom git remote helper that uses the bitbake fetcher under the hood Mar 22 15:50:42 i.e. git clone bitbake::https://github.com/foo/bar Mar 22 15:51:03 I'm not sure if this is a good idea or not, but a possibility Mar 22 15:51:36 kergoth: certainly worth exploring, I kind of like the idea Mar 22 15:51:43 yourfate: ideally add bbappends to the recipes that the files belong and add new recipes if needed Mar 22 15:52:40 ok, how do I find out which recipies they belong to? Mar 22 15:53:34 of course the remote helper would likely need to be passed settings, either via git configuration, exported vars, or re-parsing metadata, but.. hmm Mar 22 15:56:20 Hi, I need a way to create kind of a meta-recipe that installs a mini-rootfs on the target. The goal is to generate subsets of the main rootfs as LXC containers' rootfs. Any thoughts ? Mar 22 15:56:56 make a rootfs image, then in the container recipe you can depend on it Mar 22 15:57:06 and put it somewhere in the real rootfs Mar 22 15:57:44 yo dawg we heard you like rootfs. so we put a rootfs in your rootfs. Mar 22 15:57:48 Mar 22 15:58:18 So basically an image recipe with IMAGE_INSTALL_append, and then a recipe that depends on this image ? Mar 22 15:58:41 LetoThe2nd: exactly :D Mar 22 15:59:16 mjourdan: \o/ Mar 22 15:59:24 mjourdan: pretty much. you need to put the container rootfs in the right place with custom code. Mar 22 16:00:33 fair 'nough, hopefully it'll go as easily as this was to understand Mar 22 16:00:34 thanks :> Mar 22 16:06:08 RP: krogoth: thanks to both, yes it's needed for bugfix I need for morty release Mar 22 16:06:44 RP: krogoth: I'll send it to oe-core soon, just wanted to fix it in our setup ASAP and merge to morty can take a while Mar 22 16:07:11 * kergoth ponders Mar 22 16:07:25 heh! Mar 22 16:07:33 that's why it didn't autocomplete your name.. Mar 22 16:21:36 hello. can you tell me where i need to change the partition type for the img from gpt to mbr? Mar 22 16:42:23 rburton: so.. I'm having some trouble getting the files from my image. I created a very simple image recipe that inherits core-image with only one entry in IMAGE_INSTALL_append Mar 22 16:42:35 then created a recipe that depends on this image Mar 22 16:42:49 but I can't get to the image's files from that last recipe Mar 22 16:43:24 DEPENDS means do_configure depends on do_populate_sysroot of the dep Mar 22 16:43:40 your recipe probably doesn't run do_cnfigure, and do_populate_sysroot of the other recipe will do nothing Mar 22 16:43:45 you'll have to be more explicit than that Mar 22 16:44:00 i.e. do_rootfs[depends] = "some-other-image:do_image_complete" Mar 22 16:44:38 I see, let me try Mar 22 16:47:20 RP: is the required minimum bitbake version needed by the fetcher documented anywhere? Mar 22 16:47:26 RP: er, minimum git version Mar 22 16:53:57 kergoth: One part I don't understand, will my image's rootfs automagically be transfered to the recipe that depends on it ? Mar 22 16:54:06 there's no magic, no Mar 22 16:54:20 if you depend on the tasks that write the other image to DEPLOY_DIR_IMAGE, then you could grab the files from that path Mar 22 16:59:40 Do you have an example in mind ? Not sure I understand what you mean by "depend on the tasks" Mar 22 17:00:22 i just told you Mar 22 17:00:43 do_rootfs[depends] makes do_rootfs depend on do_image_complete in the other recipe. that task and its deps write images to the deploy dir where you can use them Mar 22 17:01:03 yeah that I got Mar 22 17:01:15 but how do I get access to DEPLOY_DIR_IMAGE from a recipe that simply depends on an image ? Mar 22 17:01:30 oh wait, it's global isn't it ? Mar 22 17:01:47 yes.. Mar 22 17:01:57 alright got it, thanks :D Mar 22 17:02:09 that's the point, it's writing to a dir that's available from all recipes. you can't go poking into internal recipe-specific dirs like workdir, so you have to use a shared directory for a case like this Mar 22 17:02:37 of course, for compilation sysroots are constructed with the bits from the dependencies, but you're not dealing with a sysroot here, so that's an entirely different case Mar 22 17:02:59 Yup, so in the do_rootfs { } of my recipe, I can simply install the files from the deploy dir/image-name to the recipe's image/ output Mar 22 17:04:16 right Mar 22 17:04:36 or via a rootfs pre/post process command rather than directly modifying the do_rootfs, but it's the same idea Mar 22 17:05:03 why do_rootfs instead of do_install ? What's the difference ? Mar 22 17:05:33 yeah I'll use a do_rootfs_append Mar 22 17:06:31 do_install installs files to ${D} for packaging Mar 22 17:06:46 images don't get put in binary packages, it's the other way around Mar 22 17:10:09 Okay Mar 22 17:10:34 One last thing : isn't do_rootfs only for images ? Will it be called for my "regular" recipe ? Mar 22 17:14:00 yes, do_rootfs is for images. there are many tasks run by a normal recipe, it depends on when and where you needd the image Mar 22 17:14:02 kergoth: I think its checked on OE-Core Mar 22 17:14:46 ah, right Mar 22 17:14:47 thanks Mar 22 17:14:57 need to know what features are safe to use :) Mar 22 17:18:07 Ah I see, so I should directly add the depends and do_rootfs_append in my main image recipe.. would make more sense than another recipe Mar 22 17:20:49 is there a way to run cleanall (or clean,cleansstate) for all packages in an image? Mar 22 17:20:54 if i execute `wic create directdisk -e core-image-minimal` i get "ERROR: Please build syslinux first". how do i build syslinux, so? Mar 22 17:21:23 gtg, thanks a bunch kergoth & rburton! :> Mar 22 17:32:20 hi, how do you bring up eth0 on boot with an image which uses systemd, since the networking init script doesn't seem to get called in this case... Mar 22 17:36:36 oh, nevermind, I think the issue is that the networking service is masked for some reason... Mar 22 18:07:29 well i've stopped boost trying to build py2 modules when you ony have py3 Mar 22 18:07:34 but now its not building py3 either :( Mar 22 18:26:30 hacking on boost? good luck :) Mar 22 18:34:45 kergoth: OH THE PAIN Mar 22 18:35:10 * beeker23 sigh Mar 22 18:35:32 WARNING: file-native-5.28-r0 do_fetch: Failed to fetch URL git://github.com/file/file.git, attempting MIRRORS if available Mar 22 18:35:48 pity me :-( no proper revision in that git tarball Mar 22 18:36:30 upstream fixed the changed commit id issue, skip using the mirror tarball and fetch from upstream directly Mar 22 18:40:21 luneff: try re-fetching oe/poky/whatever, they fixed the git repo Mar 22 18:43:17 thanks! I'll try Mar 22 20:13:18 so, the systemd-compat-units masks the /etc/init.d/netwokring service... how come there isn't a recipe which makes systemd bring up eth0 by default to replace that? Mar 22 20:14:25 ssalenik: use something like networkd or connman? Mar 22 20:14:56 rburton: well, networkd does run, but it doesn't bring up eth0... I only have lo up when I boot Mar 22 20:16:27 systemd doesn't even enable networkd by default, so unless you both enabled it via packageconfig and configured it, it won't be doing much, afaik Mar 22 20:16:33 s/systemd/the systemd recipe/ Mar 22 20:54:26 RP, lsandov If http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134481.html looks right to you I think patchtest will post correctly from now on. Mar 22 21:05:22 halstead: mmm content is bad, it is showing what it passed not what fail Mar 22 21:05:57 lsandov, Maybe I triggered it incorrectly? "git pw post-result 5923 patchtest failure" Mar 22 21:06:46 halstead: let me check, lets stop the cron for the moment Mar 22 21:06:54 lsandov, Okay. Mar 22 21:07:06 Stopped. Mar 22 21:08:44 hmm, adding 10 layers, each with one recipe in them, bumps bitbake's ram usage for a bitbake -e by 500 megs Mar 22 21:08:51 that seems a bit excessive Mar 22 21:09:32 bitbake -e with 57 tiny layers, each with one recipe, uses 8 gigs Mar 22 21:10:06 kergoth: I tried vmstat looking at a bitbake core-image-minimal, and free memory decrease by 20Gb Mar 22 21:10:22 kergoth: https://wiki.yoctoproject.org/wiki/Vmstat Mar 22 21:11:40 that definitely seems high Mar 22 21:12:06 kergoth: yes, bitbake is kind of a memory hog :) Mar 22 21:12:38 it always has been, really :) Mar 22 21:12:57 still, this seems excessive. when i was working on parallel parsing, it was still possible to bitbake -p with 1gb of ram available Mar 22 21:14:09 kergoth: I see, ptyhon2.7 at that time, I believe Mar 22 21:14:20 true, yeah Mar 22 21:15:31 hmm, should try doing a pyprof2calltree and examine in kcachegrind again, haven't doen that in many years Mar 22 21:19:00 kergoth: yes, that would be good Mar 22 21:22:45 wonder what other memory profiling tools are available nowadays, haven't looked into it in a while Mar 22 21:26:20 kergoth: there is one python module (memory_profiler) but this is too granular for what I think we need Mar 22 21:26:39 yeah, seems like that's line-by-line. good for the micro level, not macro Mar 22 21:26:49 kergoth: I used vmstat because it gets data from /proc, but this is too general! Mar 22 21:26:54 * kergoth nods Mar 22 21:27:24 kergoth: i believe we need to hack bitbake so we can vmstat -p PID on bitbake processes Mar 22 21:27:43 i expect we can do it similar to how the -P argument works for cpu profiling Mar 22 21:27:51 separate info for each process Mar 22 21:28:12 kergoth: yes. I also want to try Intel VTUNE Mar 22 21:29:34 mprof from memory_profiler works to get an over-time overview, but it's not granular enough Mar 22 21:29:53 halstead: did you git pw post-result manually? Mar 22 21:36:32 lsandov, Yes. I ran "git pw post-result 5923 patchtest failure" as the patchtest user. Mar 22 21:47:19 hmm, half my home network disappearing was very odd, rebooting the switch (from its webui) made it work again which is rather worrying Mar 22 21:52:31 RP, what - you don't trust stuff that magically fixes itself as being long term reliable? Mar 22 22:00:53 lsandov: the numbers don't seem right yet for some reason, but https://gist.github.com/kergoth/c0ed22a42b76972356bdd25971d157cd at least dumps mprof-style info for the cooker and each task, alongside the cprofile info. obviously still just basic stats, but it's a start Mar 22 22:00:54 hmm Mar 22 22:01:27 * kergoth grumbles Mar 22 22:59:13 kergoth: nice. that is something I wanted to do. About the numbers, I believe it is a matter of including the right parameters to the mem profiler, right? Mar 22 22:59:34 i'd expect so Mar 22 23:00:17 Not related to builds, but I have a setup here using 6gb of ram to do a bitbake -e recipe. If I disable variable tracking for -e, it uses 2.5gb instead. Mar 22 23:00:20 yikes. Mar 22 23:00:27 would be nice to make that tracking optional.. Mar 23 00:00:48 kergoth: whats your bblayers.conf like Mar 23 02:05:40 so would adding some binutils/mingw dependent glibc-gconv-* modules to the uninative tarball be acceptable? or is default uninative-tarball specifically intended to be lean on those parts of libc? **** ENDING LOGGING AT Thu Mar 23 03:00:02 2017