**** BEGIN LOGGING AT Wed Mar 29 03:00:04 2017 Mar 29 06:45:47 hello! i am not able to boot core-image-rt on intel-galileo. It always give kernel panics and say "no filesystem could mount root" can you give some suggestions? Mar 29 06:46:43 yettt: well is there a root fs for it? where is it? how do you pass it to the kernel? Mar 29 06:47:57 @LetoThe2nd it is on sdcard i have followed https://www.yoctoproject.org/downloads/bsps/morty22/intel-core2-32 Mar 29 06:49:53 you sucessfully did the whole parted-native wic shbang? no errors? Mar 29 06:51:30 i have tried different partition numbers on efi/loader/entries/boot.conf Mar 29 06:51:38 yes i have used the wic Mar 29 06:52:23 created the direct file like this: wic create galileodisk-sd -e core-image-rt Mar 29 06:53:38 well i don't have a galileo, i just look at "c. Booting the intel-quark BSP image on a Galileo board" and it seems to be quite convoluted. Mar 29 06:53:47 did the standard image boot alright? Mar 29 06:54:41 yes the standard images is just fine Mar 29 07:21:48 justanotherboy: there Mar 29 07:41:06 pohly: I wondered if you had any ideas on how to fix https://bugzilla.yoctoproject.org/show_bug.cgi?id=11042. The issue is that do_populate_sdk_ext doesn't depend on do_build so rm_work can happen before it completes :( Mar 29 07:41:08 Bug 11042: normal, Medium+, 2.3 M4, richard.purdie, NEW , Fail to build sdk_ext if enable 'rm_work' Mar 29 07:47:16 RP: I'll have a look. Mar 29 08:38:18 rburton: if there is a window on the autobuilder, can you throw this branch on it? https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/openssl-1.1 Mar 29 08:39:40 RP: the AB looked happy last night Mar 29 08:39:49 RP: ok to fire alex's branch now? Mar 29 08:41:59 morning josh Mar 29 08:43:21 I guess I could do something about those fedorahosted projects next.... Mar 29 08:43:21 rburton: yes, go for it Mar 29 08:43:39 rburton: I was thinking of merging in -next given the successful tests Mar 29 08:43:43 rburton: was quite fast too Mar 29 08:43:44 and generally do the 'Alex RRS fixing' thing Mar 29 08:43:52 kanavin: new guys are working on those Mar 29 08:44:48 rburton: I don't expect much out of openssl run, will probably be sea of red - I only tested that world builds on x86_64 Mar 29 08:44:59 RP: ^ Mar 29 08:45:03 hehe Mar 29 08:45:11 fired on https://autobuilder.yocto.io/tgrid Mar 29 08:46:00 rburton: new guys are the malaysia team, and they're working on eliminating fedorahosted references? Mar 29 08:46:17 kanavin: yes, there's a bug i filed and they own it Mar 29 08:51:15 it wasn't particularly nice of fedorahosted to go so cold turkey :-/ Mar 29 08:51:22 no Mar 29 08:51:33 even fedora still points at it Mar 29 08:51:34 they should've provided pointers to the new locations for everything they host, and *then* pull the plug Mar 29 08:51:44 ie xmlto.spec still has fedorahosted as the source0 Mar 29 08:52:04 presumably they also have a giant source mirror Mar 29 08:52:08 rburton: yeah, I couldn't find the new place for xmlto either Mar 29 08:52:24 I guess we'll use our favorite standby, debian snapshots for that Mar 29 08:52:28 yeah Mar 29 08:52:53 i looked at a few as worked examples for the new people, some are dead and some have just moved Mar 29 08:53:01 logrotate moved a while ago so we're missing some upgrades Mar 29 08:54:16 I assume that this "eliminating fedorahosted references" doesn't include meta-oe, but I'll send couple fixes for do_fetch issues in meta-oe today Mar 29 08:55:05 JaMa: phase one is oe-core, yes. i suspect meta-oe has a higher ratio of proper dead upstreams. Mar 29 08:55:34 re-evaluating everything which turns out to be dead should happen in the 2.4 cycle Mar 29 08:56:02 ie does lsb still mandate chkconfig Mar 29 08:56:04 I'm fixing only those where SRC_URI used git:// for fedorahosted, because normal archives are still fetched fine from OE source mirror Mar 29 08:56:37 jesus google is spooky Mar 29 08:56:54 search lsb, too many unrelated hits. type linux and it autocompetes "standard base" Mar 29 08:59:09 rburton: my favorite used to be microsoft search engine, bing or whatever its called Mar 29 08:59:41 rburton: if you search for linux, the top two links are microsoft articles on how to deinstall it and why windows has a better TCO Mar 29 09:02:34 lol Mar 29 09:47:35 alimon: RRS is again not up to date Mar 29 09:47:44 alimon: still shows we have rpm 5 for instance Mar 29 09:55:59 kanavin: :( Mar 29 10:43:48 Yocto can produce a bootable fs image correct ? Mar 29 10:44:24 Less obscure question is: What is used to create the image without requiring root to do so ? Mar 29 10:45:58 gtristan: you already bitbaked an image like core-image-base ? Mar 29 10:46:15 you can then use wic to create an sd card image or other complete images Mar 29 10:46:19 yourfate, it's been a while, almost a year since I've done that Mar 29 10:46:25 wic Mar 29 10:47:11 I see, another incarnation of mic, sortakinda Mar 29 10:47:42 yourfate, any idea what precisely this does ? Mar 29 10:48:17 yourfate, I'm looking into using libguestfs tools with fuse, which seems to work well with most any fs type Mar 29 10:48:26 and was wondering what yocto is doing Mar 29 10:48:49 gtristan: we have a tool called pseudo which emulates certain root operations. We also have ensured tools like mke2fs can work without needing loopback mounts Mar 29 10:50:53 RP, I see, so mke2fs on an image file, and then some related tooling lets you do some kind of mount without loopback device ? Mar 29 10:51:02 I suppose it's ultimately also a fuse mount ? Mar 29 10:51:39 gtristan: no, we never need to mount anything Mar 29 10:53:17 ah Mar 29 10:53:35 RP, so mke2fs -d path/to/sysroot, basically ? Mar 29 10:53:49 gtristan: yes, something like that Mar 29 10:53:58 I see, ok thanks Mar 29 11:20:42 hmmm, so with this approach, it is not possible to ... run extlinux --install /new/system/mountpoint Mar 29 11:22:08 kanavin: musl and no-x11 are failing on the ab Mar 29 11:22:51 huh okay my desktop is utter frozen Mar 29 11:22:55 bbiab Mar 29 11:27:48 kanavin: also, x86 exploded in core-image-sato-sdk Mar 29 11:32:37 hello Mar 29 11:32:59 kanavin, i have one problem ref. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 Mar 29 11:33:00 Bug 10450: normal, Medium+, 2.3 M4, alexander.kanavin, IN PROGRESS DESIGN , Reduce fuzz factor when patching files Mar 29 11:33:26 kanavin, is there any document stating that the default patch 'fuzz' value is 1? Mar 29 11:34:14 this is indeed the behaviour we see in poky Mar 29 11:35:15 the manual page says: (The default maximum fuzz factor is 2.) Mar 29 11:35:43 or maybe i misunderstand this 'fuzz' thing Mar 29 11:35:49 cornel: which manual is that? Mar 29 11:35:55 man 1 patch Mar 29 11:36:18 jku, ^ Mar 29 11:36:58 cornel, kanavin was almost certainly referring to the value that oe/yocto uses by default when applying patches Mar 29 11:37:14 jku, i see Mar 29 11:37:40 but in patch.py the fuzz is left at the default Mar 29 11:37:56 so, it is a bug in patch (documentation)? Mar 29 11:38:09 or is the default 'fuzz' value set anywhere else? Mar 29 11:38:16 in yocto^ Mar 29 11:40:36 that's a good question, I haven't looked myself Mar 29 11:40:51 jku, thank you :) Mar 29 11:41:01 jku, but i'm really concerned by this Mar 29 11:41:32 but maybe, actually kanavin is wrong, let me look at something Mar 29 11:43:56 nah, i am not paying attention, he did not said that defaul fuzz value is 1 Mar 29 11:44:31 cornel also fuzz means "how many lines are allowed to be different" Mar 29 11:44:54 if I read it right Mar 29 11:45:23 then i definitely do not understand 'fuzz' Mar 29 11:46:39 anyone tried linaro external toolchain? Mar 29 11:47:01 getting a ton of installed-vs-shipped /usr/share/i18n/charmaps/IBM871.gz on glibc-locale-linaro Mar 29 11:47:36 jku, you're definitely right Mar 29 11:47:54 and then everyone is right but me Mar 29 11:48:48 well you're probably right that we use the default fuzz which is two Mar 29 11:53:43 jku, yes, but nobody contradicted this :) Mar 29 11:53:55 i've just misunderstood the bug report Mar 29 11:55:24 i'm still not 100% sure that the context lines ignored are form exterior toward the middle of the change, but for now it's a good enough assumption Mar 29 11:56:05 also, if context is +/- 3 lines, i expect --fuzz=2 to count the total number of context lines from the middle of the change Mar 29 11:56:27 as opposed to margin Mar 29 12:16:20 So last week I got a bounce from my jpeg turbo patch: http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134615.html ... seems the bot is very selective about the email Mar 29 12:16:44 The patch was against morty, but I rebased it to apply against master now: http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134849.html Mar 29 12:17:19 And I dont understand why it would complain about signed-off-by, I would think one would sign off on it, only _after_ receiving it through the oe-core email Mar 29 12:17:52 anyway, I hope to unsubscribe from this high-traffic list asap :-S Mar 29 12:21:16 gtristan: we do require your signed-off-by in the patch submission Mar 29 12:23:02 jku, I filed the bug with patch attached, and rburton asked for an additional mail to the list Mar 29 12:23:06 gtristan, are you subscribed to any other OE/YP lists? Mar 29 12:23:08 jku, so what is the process from here ? Mar 29 12:23:21 Crofton|work, unfortunately, I needed to subscribe yes Mar 29 12:23:26 openembedded-core Mar 29 12:23:31 one issue we have is contacting users and developers reliably Mar 29 12:23:48 but you want off that one :) Mar 29 12:24:14 Well, its huge traffic of mostly stuff that... well it's basically email version of bugzilla :-S Mar 29 12:24:30 and you are not on any other lists? Mar 29 12:24:56 I am on plenty of lists :) none of them are really yocto related Mar 29 12:25:05 * Crofton|work is just colelcting data about how we can better announe things like devleoper meetings, currently I send to about 5 lists Mar 29 12:25:18 The thing about yocto is, I will generally go for many months, until something pops up and I have to fix some bug Mar 29 12:25:35 then I just want to hit and run, and wont be patching anything for another 6 months Mar 29 12:25:54 usually its about building on aarch64 hosts Mar 29 12:26:09 (for either aarch64 or armv7a targets) Mar 29 12:26:14 I understand completely Mar 29 12:26:49 this means we are doing a lot of things right Mar 29 12:26:58 Heh Mar 29 12:29:03 gtristan: you'll have to resend with the signed-off-by. Please send patches inline (the last one was not) Mar 29 12:29:32 You want the patch not as an attachment ? Mar 29 12:29:46 And signed off... but signed off by whom ? Mar 29 12:31:10 hi, I'm trying to have a task disable/remove other tasks from within the python implementation, nothing I've tried works (d.setVarFlag("task", "noexec", "1"), bb.util.deltask("task") etc), is it even doable ? Mar 29 12:32:06 I got it working using an anonymous python function (that set the "noexec" flag to "1" on the tasks to disable), but I'd rather have this implemented as a task that runs before all others Mar 29 12:32:21 gtristan: signed off by you: it's your "promise" that e.g. you have the right submit those changes. I realise it's a bit stupid for a few tiny changes, but... Mar 29 12:34:16 jku, alright, the email title line is alright ? just put the `git format-patch` output as the email content ? Mar 29 12:34:50 I see this after changing the MACHINE with a jethro build Mar 29 12:34:50 http://paste.debian.net/924930/ Mar 29 12:34:50 Basically, do_populate_sysroot_setscene fails because tar: ./usr/lib/perl5: Cannot create symlink to 'perl': File exists Mar 29 12:34:50 look slike removing the sysroot and starting over for new machine solves the problem, but this is eally annoying Mar 29 12:36:41 gtristan: latest one looks good to me . If possible use [PATCHv3] in the subject instead of [PATCH] to show that this is the third submission Mar 29 12:37:01 it looks like the functions used with the `d` variable do work (__BBTASKS is updated properly), but then the execution flow keeps going regardless of the changes made in the first task Mar 29 12:37:05 scripts/[create|send]-pull-request are your friends :-) Mar 29 12:37:09 hmmm, i've just found two patches that are NOT applied at all, but i had no idea about it. is there a log file were such cases are logged by bitbake? Mar 29 12:38:28 jku, Ok have it in my email composer right now... so the entire content of the email should just be the patch ? Mar 29 12:38:35 or maybe i'm wrong again? Mar 29 12:38:45 hmmm, have to check again :( Mar 29 12:38:57 or "inline email attachment" (is that even a thing ?) Mar 29 12:40:58 cornel: I use "git send-email" or the scripts joshuagl suggested. What you described _should_ work but if you do any copy-pasting that can lead to problems... Mar 29 12:41:22 oops sorry, that was for gtristan Mar 29 12:41:51 cornel: check $WORKDIR/temp/log.do_patch Mar 29 12:41:52 no worry Mar 29 12:41:53 * gtristan fires it off and crosses fingers Mar 29 12:42:02 thank you jku Mar 29 12:42:02 git send-eaml is your freind Mar 29 12:42:13 I have a git send-email alias for single patches, then I can run oemail HEAD~1 Mar 29 12:42:55 jku, http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134851.html Mar 29 12:43:03 from the meta-oe README: When sending single patches, please use something like: Mar 29 12:43:03 'git send-email -M -1 --to openembedded-devel@lists.openembedded.org --subject-prefix=meta-oe][PATCH' Mar 29 12:43:14 for that layer, I just cut/paste from the README :) Mar 29 12:43:34 looks like the bot did not mind the attached-ness of the patch and only complained about signoff (last patch) Mar 29 12:44:48 clearly we need to replace the patch management software with some machine learning application Mar 29 12:44:54 * gtristan thinks you would not need signed-off-by if you just mandated that patches are submitted in `git format-patch` format Mar 29 12:50:25 so i was wrong again: the patches were already applied by bitbake, but i did not understood the process Mar 29 13:17:41 kanavin, i'm trying to backport the fuzz=0 patches from morty (?) to 'jethro. how can i commit them? (for now i only have automake ;)) Mar 29 13:22:59 hi everyone Mar 29 13:23:17 hi aurele Mar 29 13:23:50 would it be possible to list all recipes/packages compiled for an image with a specific value in SECTION variable? Mar 29 13:31:38 bitbake -g may provide some intermediate results Mar 29 13:31:58 once you get the recipe list, you can grep in Mar 29 13:43:42 cornel, thanks I will try to script something with this Mar 29 14:11:49 sigh Mar 29 14:11:54 patch fail, again Mar 29 14:12:36 Must the patch absolutely be inline in the message content, cannot be an attachment ? Mar 29 14:12:43 Seems the bot ate that up just fine before Mar 29 14:13:03 sorry to insist guys, has anybody managed to disable arbitrary tasks from the first one to be executed? I tried using "noexec" and `bb.build.deltask` to no avail, the code is executed but the tasks are still run Mar 29 14:25:52 ironzorg: I think you need to be clearer about the issue you're seeing as I couldn't parse that sentence Mar 29 14:25:53 actually I could fix things if I knew why my recipe is parsed four times, I can see "Resolving any missing task queue dependencies" several times in my logs Mar 29 14:26:32 RP: I'm adding a task that runs before all the other tasks of a given recipe, and trying to make that task disable all the others Mar 29 14:26:56 ironzorg: Multiple "Resolving any missing task queue dependencies" sounds odd. Are you using bitbake -k ? Mar 29 14:27:20 no I'm not Mar 29 14:27:45 ironzorg: at what point are you trying to "disable the others"? at task execution time? Mar 29 14:28:01 I basically do `C = "${@foo(d)}"; def foo(d): d.setVarFlag("do_build", "noexec", "1")` Mar 29 14:28:27 right now I'm doing like the above, but yea I tried something along those same lines in an actual task (when the task is being executed) Mar 29 14:28:46 well, at task execution time won't work since the tasks can't change each others metadata Mar 29 14:28:54 ok so that's settled Mar 29 14:29:06 the above is creative, it depends how you're triggering ${C} I guess Mar 29 14:29:58 my usecase above was very trimmed up, I actually run a process in the `foo` function, and the fact that it runs four times is not convenient Mar 29 14:30:51 I appreciate the reply though RP, thanks for that Mar 29 14:30:52 ironzorg: I know why it would reparse, are you sure you;re seeing "any missing task queue dependencies" multiple times though? Mar 29 14:31:42 ironzorg: the trouble is parsing happens in multiple contexts, the base configuration, then the base configuration can get updates after config changes, then the recipes parse and each recipe may parse multiple times for variants (native, nativesdk, multilib and so on) Mar 29 14:31:51 also, the workers all reparse Mar 29 14:32:45 nope, no such message in the output Mar 29 14:33:11 ironzorg: you did say 'I can see "Resolving any missing task queue dependencies" several times in my logs' Mar 29 14:33:20 I tried detecting whether `C` was already set, but ran into exceptions probably because of the context switch you mentioned Mar 29 14:33:28 yes, 4 times exactly Mar 29 14:33:47 misread you Mar 29 14:33:48 I don't understand that. As I said, multiple parses do happen though. Mar 29 14:34:05 they're even in different processes (worker verses server) Mar 29 14:34:34 so I guess I'll have to cache the results of my process somewhere so that it doesn't get run several times in a row Mar 29 14:34:44 probably Mar 29 14:34:57 alright that was instructive, thanks Mar 29 14:35:03 the persist db thing in bitbake may help there fwiw Mar 29 14:35:20 oh Mar 29 14:36:13 lib/bb/persist_data.py in bitbake Mar 29 14:36:32 cheers Mar 29 14:44:28 hello Mar 29 14:44:41 could anyone share a boilerplate HOSTTOOLS that would be great Mar 29 14:44:44 thanks Mar 29 14:49:41 robsta: boilderplate? Mar 29 14:50:10 RP, ross: yes, I saw - unfortunately introducing openssl 1.1 is harder than I thought, as we need to go out and fix all upstreams that are incompatible with 1.1 - I thought we could get away with not doing that and making 1.0 and 1.1 coexist. It doesn't work because openssl11-dev and openssl10-dev directly clash. Mar 29 14:50:24 robsta: our current default is http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n457 Mar 29 14:50:30 there's maybe 6 such upstreams. Mar 29 14:51:06 kanavin: or you just delete the contents of openssl10-dev :} Mar 29 14:51:25 I'm sure it wasn't me who suggested something so evil Mar 29 14:51:33 RP: yes :) perhaps! Mar 29 14:53:15 rburton: ^^^ Mar 29 14:54:06 kanavin: I guess at build time, rss lets you do this now when it was never possible before Mar 29 14:54:22 that is cool and scary :/ Mar 29 14:55:55 RP: yes, before rss we would get nowhere at all with this, and would have to wait until most of the recipes would be ported, and fix the remaining ones Mar 29 14:56:30 joshuagl: runqemu is failing for me in refkit after updating to more recent bitbake and OE-core with: Mar 29 14:56:30 Overriding conf file setting of STAGING_DIR_NATIVE to /fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/defaultpkgname/1.0-r0/recipe-sysroot-native from Bitbake environment Mar 29 14:56:48 cornel: I don't undestand what you are trying to do and why Mar 29 14:57:09 Note the "defaultpkgname" in the path. Of course there is no such recipe-sysroot-native, so later it fails to find tunctl etc. Mar 29 14:57:38 pohly: that is with what is effectively master? Mar 29 14:57:46 RP: yes Mar 29 14:57:58 pohly: Robert added some patches in this area recently Mar 29 14:58:01 Exactly master. Mar 29 14:58:30 pohly: I think you've touched runqemu more recently than me ;-) Mar 29 14:58:32 pohly: defalutpkgname means it comes from bitbake -e with no recipe set Mar 29 14:58:45 The "Overriding conf file setting of" code is still from joshuagl (commit 1e8165ea2f1). Mar 29 14:59:23 pohly: ah :) Mar 29 15:00:27 $ bitbake -e | grep ^STAGING_DIR_NATIVE= Mar 29 15:00:27 STAGING_DIR_NATIVE="/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/defaultpkgname/1.0-r0/recipe-sysroot-native" Mar 29 15:00:36 I think that's what's breaking runqemu. Mar 29 15:02:26 But that has been in meta/conf/bitbake.conf. Something must have changed in runqemu such that it now finds and uses that variable. Mar 29 15:04:55 joshuagl: any idea how your code is supposed to work now? There is no single STAGING_DIR_NATIVE anymore, so why does the variable from "bitbake -e" matter? Mar 29 15:05:47 pohly: I'm sorry, I'm on a different coal face nowadays so not entirely certain how to address that in an RSS world Mar 29 15:06:21 although I suspect we can look at wic for inspiration? Mar 29 15:11:05 I suspect enabling rm_work.bbclass triggered it: runqemu looks for the STAGING_DIR_NATIVE and STAGING_BINDIR_NATIVE of the image that it is asked to boot. But those directories get removed by do_rm_work, and the fallback code then ends up using the broken path from bitbake -e. Mar 29 15:11:51 I'd guess the code I introduced in 1e8165ea2f1 to guess an appropriate path based on OE_TMPDIR is equally bogus now too? Mar 29 15:12:28 joshuagl: probably. Mar 29 15:13:08 cheers RP Mar 29 15:29:52 RP: why is gcc in HOSTTOOLS? Mar 29 15:30:00 for bootstrapping? Mar 29 15:31:08 robsta: how would you build any native tool, including gcc itself? Mar 29 15:59:01 kanavin: the upgrade is only registered in the RRS when the version is grater than the previous one... :/, i don't expect to have "reverse upgrades" in the recipes Mar 29 15:59:27 kanavin: i remember that we have rpm4 and rpm for that reason or something like that Mar 29 16:06:51 kanavin: i will register the new rpm 4 version manually... Mar 29 16:10:54 alimon: does RRS not respect epoch? Mar 29 16:12:12 rburton: what you mean with epoch, the modification time in git commit? Mar 29 16:12:17 no, PE Mar 29 16:12:27 the version in the recipe didn't go down Mar 29 16:12:35 it went from 5.something to 1:4.something Mar 29 16:12:40 which is an upgrade :) Mar 29 16:13:31 rburton: nop i didn't code that kind of logic, RRS only sees PV Mar 29 16:13:50 there's a few recipes that use PE, so would be good to handle it Mar 29 16:13:59 rburton: yes will be good Mar 29 16:14:08 i didn't know about PE since now Mar 29 16:14:28 its a normally invisible to the user version prefix Mar 29 16:14:37 for situations like this Mar 29 16:14:49 default PE is 0, so 1:4 sorts higher than 0:5 Mar 29 16:15:03 rburton: yes i got it Mar 29 16:31:49 What does one do when he sees 'TouchPointPressed without previous release event QQuickEventPoint(valid:true acc Mar 29 16:31:49 epted:false state:Pressed scenePos:QPointF(409,634) id:1 timeHeld:0)' for Qt/Wayland/Weston combo? The touchscreen seems to be identified properly. Wayland recieves frame and movement events yet clicks are not working :-( Mar 29 16:48:12 denix RP right; but for my cause i might have to distinguish between bootstrapping and normal operation Mar 29 16:49:55 robsta: FWIW some software has native tools which it builds with gcc and target pieces which it builds with gcc-cross Mar 29 16:50:41 robsta: wayland for example uses pkg-config-native even Mar 29 16:51:09 pieces of u-boot is another example Mar 29 20:01:18 RP: fair enough, thanks again Mar 29 20:01:57 maybe we can restrict the hosttools after bootstrapping Mar 29 20:02:21 RP: after 9a23af3 The postinstall intercept hook 'update_gio_module_cache' failed Mar 29 20:06:51 which leads to: The postinstalls for the following packages will be postponed for first boot: libglib-2.0-0 Mar 29 20:07:02 revert tested Mar 29 20:38:48 robsta: there are certainly options for doing that Mar 29 20:40:06 ant_home: that seems odd. any idea what the error in the postinst is? Mar 29 20:46:54 RP: I'm reverting the revert..one moment Mar 29 20:53:30 RP: kergoth: Mar 29 20:53:32 NOTE: Running intercept scripts: Mar 29 20:53:32 NOTE: > Executing update_gio_module_cache intercept ... Mar 29 20:53:32 chown: cannot access '/tmp/build/tmp-glibc/work/c7x0-oe-linux-gnueabi/core-image-base/1.0-r0/rootfs/usr/lib/gio/modules/giomodule.cache': No such file or directory Mar 29 20:54:11 ant_home: so I wonder what it did create? Mar 29 20:55:17 the file is not there...dir empty Mar 29 21:00:58 RP: the full log https://filebin.net/gwk8zgxkbv0j0nax/log.do_rootfs.9236 Mar 29 21:08:47 ant_home: which makes me wonder what the qemu call actually did... Mar 29 21:09:13 the permissions of the dirs and files seem normal Mar 29 21:10:50 hm.. under /intercept_scripts some are executable, others not Mar 29 21:10:52 base/1.0-r0/intercept_scripts$ ls -al Mar 29 21:10:52 total 20 Mar 29 21:10:52 drwxr-xr-x 2 andrea andrea 140 mar 29 22:51 . Mar 29 21:10:52 drwxrwxr-x 10 andrea andrea 240 mar 29 22:52 .. Mar 29 21:10:52 -rwxr-xr-x 1 andrea andrea 2326 dic 29 23:34 postinst_intercept Mar 29 21:10:53 -rw-r--r-- 1 andrea andrea 251 dic 29 23:34 update_font_cache Mar 29 21:10:55 -rwxr-xr-x 1 andrea andrea 322 mar 29 22:51 update_gio_module_cache Mar 29 21:10:57 -rw-r--r-- 1 andrea andrea 273 dic 29 23:34 update_icon_cache Mar 29 21:10:59 -rw-r--r-- 1 andrea andrea 378 dic 29 23:34 update_pixbuf_cache Mar 29 21:17:12 ant_home: I tried and it didn't reproduce locally... Mar 29 21:17:18 ant_home: different MACHINE mind Mar 29 21:23:48 I wonder if it doesn't produce the cache in cases where no gio modules are installed, and that results in the error? we've been using that for ages with a number of different imgaes, though, with and without it.. Mar 29 21:23:48 hmm Mar 29 21:41:05 kergoth: I'd appreciate the help in figuring it out if you could... Mar 29 21:43:42 The obvious answer is to just add a conditional, only chown when it exists. It may be worth doing that and then investigating the root cause in parallel Mar 29 21:50:20 kergoth: right, the cause just worries me a bit Mar 29 21:50:33 kergoth: and a worry we could swallow the qemu command exit code :/ Mar 29 23:26:21 hi everyone Mar 29 23:26:58 is there a way in yocto to define some services to start at an image level/in local.conf? Mar 29 23:27:41 right now the only thing i can see is inheriting update-rc.d in the recipe (but the application in the recipe isn't really a service inherently, it is just the main application of the device) **** ENDING LOGGING AT Thu Mar 30 03:00:01 2017