**** BEGIN LOGGING AT Tue Apr 11 03:00:05 2017 Apr 11 05:28:29 Hi all, how to add useradd package in my yocto rootfs, I have core-image-minimal currently Apr 11 05:58:59 RP: I can confirm that your patch (with the fo_fetch typo fixed) fixes the recipe-sysroot problem for fetch. Apr 11 06:04:42 RP: arkver: thank you very much for your work (and sorry for leaving without a notice) yesterday! You guys are awesome. I'll test that mentioned patch and come back to you! Apr 11 06:21:59 g0hl1n: np. Glad RP had the flash of insight to spot the problem. Apr 11 06:42:42 bluelightning: have you seen my comment on the diffsigs patch series about recursive diff not finding signature files? Apr 11 06:43:48 g0hl1n: Just noticed that RP posted a corrected version of his original quick hack on the mailing list. Apr 11 06:44:35 staging: Fix sysroot problem with populate_sysroot dependencies on do_fetch Apr 11 06:45:17 arkver: yes, and he already pushed and reverted it again in the master branch: https://git.yoctoproject.org/cgit.cgi/poky/log/?id=0793c758b15e5007b4dd4b146987a0e74d6f6cba Apr 11 06:45:46 oh. :-( Apr 11 06:47:00 yes... :-( I checked out the 177d4be3c1714270e4d94fcea3106934a7d5c6e5 rev and it really "broke" my build... seems we need another solution. Apr 11 07:01:31 arkver, g0hl1n: I do understand what happened, just need to post a fixed version Apr 11 07:01:49 arkver, g0hl1n: sorry, the original had an issue Apr 11 07:05:21 RP: who is preparing OE-core master-next while you are away this week? Apr 11 07:07:39 pohly: it would be ross. Since ross is out too, I basically said I'd do it whilst away Apr 11 07:07:53 pohly: its proving a lot of work to deal with some of the patches though Apr 11 07:08:38 RP: I was hoping that I wouldn't have to bother you ;-/ Apr 11 07:09:06 pohly: it was fantasy I'd manage. What's up? Apr 11 07:09:38 pohly: I know I have the wrong version of the python makefile patch and that the libsolv patch breaks musl Apr 11 07:10:04 Do you want fixes for the go-cross and gdb-cross signature issues in M4? gdb-cross seems uncontroversial, but go-cross is a bit more tricky: removing libgcc from DEPENDS seems to work, but I have no idea whether it's correct. Apr 11 07:10:44 pohly: gdb should go in, yes Apr 11 07:10:57 pohly: I'm not happy about making go TUNE_PKGARCH Apr 11 07:11:16 dropping libgcc from the non-target version I'm happier about Apr 11 07:11:34 pohly: have you tried asking Khem? Apr 11 07:11:51 I can post a patch for the libgcc removal, but I can't guarantee that it'll work. I'll CC Khem on the patch. Apr 11 07:11:52 khem: you're not still around by any chance? :) Apr 11 07:12:14 pohly: lets post it and ask for testing Apr 11 07:12:19 yep Apr 11 07:13:13 I'm also working on further enhancements to yocto-compat-layer. The commits in master are fine, but the ones in master-next are still a bit experimental. I should have something better today. Apr 11 07:13:48 pohly: I was going to ask about those. I should drop them? Apr 11 07:14:39 Yes, better drop them for now, lest they go into master accidentally. Apr 11 07:15:10 pohly: ok, thanks Apr 11 07:15:25 I don't think we have any testing of that code (and probably should have!), so it won't make a difference for autobuilder test results. Apr 11 07:15:45 pohly: right, it was a reminder for me to talk to you about those Apr 11 07:22:57 RP: ok, thank you! Will you post that patch here or on the ML or push it directly? Apr 11 07:24:47 g0hl1n, arkver: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=5069030ab47197260d169fc5b96483ef2b8f1f90 is the corrected patch Apr 11 07:25:00 g0hl1n: I'll post it shortly Apr 11 07:28:24 RP: subtle, that extra False. Apr 11 07:30:43 arkver: yes, but very very important Apr 11 07:30:59 arkver: Its destroyed my local work area, having to totally rebuild here :/ Apr 11 07:32:31 RP: oops. :) Apr 11 07:34:14 RP: another gdb-cross signature issue, this time for gdb-cross-powerpc64 do_unpack: https://pastebin.com/BJ7Y5HcN Apr 11 07:35:11 TUNE_FEATURES changed, and is in the "Task dependencies". Apr 11 07:35:35 Any hint why do_unpack depends on TUNE_FEATURES? Apr 11 07:36:10 RP: arkver: ok, then I'll also try a complete rebuild. Only applying that patch on current master and run bitbake in the existing builddir fails with lot's of python errors... Apr 11 07:38:05 RP: g0hl1n: patch works for me, but all I've done is the wmiconfig fetch task. Will do something a bit more exhaustive in a mo. Apr 11 07:43:39 pohly: run bitbake-diffsigs (or bitbake-dumpsig) against one of the files and look at the dependencies, grep for TUNE_PKGARCH, see what depends on that and trace it Apr 11 07:59:10 RP: arkver: running "bitbake wmiconfig" in a fresh builddir with the latest patch applied on master works perfectly! I'll try that also for my own recipe (where I found the issue), but I'm pretty optimistic that's the solution. Thank you guys! Apr 11 08:01:38 RP: nothing stands out to me. If you are bored, perhaps have a look: https://pastebin.com/J7si1kLj Otherwise let's ignore for now. I was hoping to not have issues caused by OE-core itself when proposing the per-machine signature checks, but perhaps that's too ambitious and needs to be sorted out later. Apr 11 08:06:32 RP: arkver: ok, I was too overhasty :-(, wmiconfig fetch and build were ok, but there is now an error during "do_populate_sysroot": https://gist.github.com/rleitner/3e71c70e8f75f90c6a6bf11998d66ced Apr 11 08:08:12 g0hl1n, arkver: I've realised there is another issue with that patch, my own builds aren't working either Apr 11 08:08:25 g0hl1n: not sure how to fix it right now but am thinking on it Apr 11 08:10:20 pohly: its List of dependencies for variable TARGET_ARCH is {'TUNE_ARCH'} Apr 11 08:10:55 pohly: I wonder how the other cross recipes get away with it? Apr 11 08:12:46 RP: for other machines, or other recipes for that particular combination of machines? There were lots of errors for that combination, I just picked gdb-cross because we had already looked at that. Apr 11 08:14:03 pohly: I think this is something about ppc highlighting there is in fact a bigger issue here Apr 11 08:15:01 pohly: I suspect we need a TARGET_ARCH[vardepvalue] = "${TARGET_ARCH}" in the gcc-cross and gdb-cross recipes Apr 11 08:15:05 and how this ever worked... Apr 11 08:18:42 RP: just for my understanding, TARGET_ARCH[vardepvalue] = "${TARGET_ARCH}" basically tells signature hashing to ignore the first level of TARGET_ARCH expansion? Apr 11 08:19:08 I can test that, but I don't understand enough to write a proper explanation of the fixt. Apr 11 08:21:03 RP: binutils-cross has the same issue - should that line go into cross.bbclass? Apr 11 08:24:19 pohly: It means "only care about the absolute value this variable ends up with, not how its constructed" Apr 11 08:24:46 pohly: so its basically shortening the hash information to the end result, which in this case is what we care about Apr 11 08:25:10 pohly: I'm torn on cross.bbclass. There are some places cross is used where this might not be appropriate :/ Apr 11 08:25:15 or I worry there might be Apr 11 08:28:22 I can copy it into the affected recipes instead. Apr 11 08:28:52 Oh dear, what did I get myself into when volunteering to write per-machine signature checks? ;-} Apr 11 08:29:23 "Let sleeping dogs lie" and all that - not! Apr 11 08:32:22 g0hl1n, arkver: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=a43c494c82a66624d8d3cb685322cf86065be159 is my next try. Sorry about this, as you can tell, its tricky code :/ Apr 11 08:32:38 pohly: welcome to my world ;-) Apr 11 08:36:11 RP: ah, no problem and thanks for these fast responses. I'll give that new patch a try. Apr 11 08:53:01 RP: another one - gnu-config-native do_populate_sysroot: List of dependencies for variable RECIPE_SYSROOT changed from '{'MLPREFIX'}' to 'set()' Apr 11 08:53:02 Dependency on Variable MLPREFIX was removed Apr 11 08:53:02 Variable RECIPE_SYSROOT value changed from '${WORKDIR}/${MLPREFIX}recipe-sysroot' to '${WORKDIR}/recipe-sysroot' Apr 11 08:54:16 b4420qds-64b, p5020ds-64b have MLPREFIX set, intel-core2-32, intel-corei7-64, intel-quark, imx53qsb don't. Apr 11 09:03:21 Hi, do you know how to add gstreamer plugins linked to IPU ? I added gstreamer-imx plugins but I get only VPU ones. Thanks. Apr 11 09:22:49 pohly: multilib.conf being inherited? Apr 11 09:32:36 RP: looks like it. Is that legal for a machine conf? And if so, should it affect gnu-config-native? Apr 11 09:33:55 It feels wrong to change that on a per-machine basis, in which case the test has found a real BSP bug. Apr 11 09:33:59 pohly: not really, no, its a distro decision Apr 11 09:34:53 Yeah! The test works as intended :-) Apr 11 09:46:35 Looks like the cert for layers.openembedded.org had expired Apr 11 09:47:50 Anyone around who can renew that? halstead? Apr 11 09:56:07 Hi! In a bbapend, how can I prepend code that I want executed after the main recipe's own prepend ? Apr 11 09:56:50 Like : MainRecipe:function_prepend -> bbappend:function_prepend -> function Apr 11 10:00:07 pohly: yes I did, I didn't investigate it yet... can you please file a bug so I don't forget again? thanks! Apr 11 10:07:28 RP: applying the latest patch, fetching from svn and building seems to work fine again! Thanks! Apr 11 10:08:32 jku: how is that DISTRO_FEATURES patch looking? Apr 11 10:09:34 jku: There is a patch, libsdl: enable X11 for nativesdk which makes me think we really need to solve this properly for native and nativesdk (and remove rburton's x11 native tweaks in favour of a better solution) Apr 11 10:13:45 Hi! I'm working with a Zynq Board and an poky image. Because I use different peripherals I have to modify the default bitstream. I couldn't figure out how the bitstream is created by bitbake, so does someone here know? Apr 11 10:43:03 RP: I can send a new version, just got sidetracked with issues with "api-documentation": as far as I can see unrelated ones Apr 11 10:43:26 jku: please Apr 11 10:44:00 jku: I suspect we may need to extend it to cover x11 settings for native/nativesdk independent of target distrofeatures Apr 11 10:58:44 RP: sent. I used a filter list (so "these features are allowed to be set for -native"). Does that seem reasonable? Apr 11 11:00:07 jku: waiting on mail from the list... Apr 11 11:05:43 jku: sorry to be picky, but can we set it to DISTRO_FEATURES_FILTER_NATIVE + DISTRO_FEATURES_NATIVE and then add x11 to DISTRO_FEATURES_NATIVE? Apr 11 11:05:59 jku: and then add an x11 DISTRO_FEATURES_NATIVESDK ? Apr 11 11:07:17 sure. I should get more familiar with nativesdk, but as it is I don't really know what I'm doing there... but I can do what you said Apr 11 11:07:58 jku: basically the same deal as native, see that patch I mentioned above. This is a cleaner/better way of fixing that (enable x11 for nativesdk) Apr 11 11:08:29 jku: I'm trying to one mechanism to solve multiple problems Apr 11 11:20:51 RP: what does bitbake-diffsigs mean with "Taint (by forced/invalidated task) changed from nostamp:295a82e2-e509-4c0a-8199-2db01d646be9 to nostamp:cd987ec9-18f4-468d-91b5-074fe69a3189"? Apr 11 11:21:15 pohly: it means the task was "nostamp" and hence rebuilds every time Apr 11 11:21:22 pohly: the taint is how it internally ensures this Apr 11 11:21:30 pohly: same as what the -f flag does Apr 11 11:21:46 Happens to "merge-files:do_unpack" when adding the meta-intel layer. Apr 11 11:21:59 pohly: sounds bad Apr 11 11:22:20 pohly: these checks uncover all kinds of "fun" :/ Apr 11 11:22:25 It's a new problem, I've not seen that last week. Apr 11 11:22:30 As I'm pretty sure that the SVN fetcher issue is resolved, I found another problem during migrating my stuff to current master: When building my kernel recipe I get following error: run.do_validate_branches.5913: kgit-s2q: not found Apr 11 11:22:52 The obfuscated kernel recipe is available here: https://gist.github.com/rleitner/61533dff1a9210ce30fce5d32ed5aa36 Apr 11 11:23:19 Hmm, I also changed my bblayers.conf a bit. Apr 11 11:24:46 g0hl1n: lines like do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot" add in the dependency Apr 11 11:25:09 g0hl1n: you might need a line for your do_validate_branches if that comes before do_kernel_metadata Apr 11 11:40:39 Hmmm should the go_map_arch really raise a SkipPackage? I'm getting "go_1.8.bb: Exception during build_dependencies for GOARCH" warnings on a non-'go' arch Apr 11 11:42:10 nrossi: it somehow needs to flag its unbuildable... Apr 11 11:43:19 RP: is there something i need to set for this arch? just seems odd that its warning about go without doing anything with go :| Apr 11 11:46:19 nrossi: I suspect the handler needs to pass that rather than trap it Apr 11 11:48:23 nrossi: care to test a patch? Apr 11 11:48:29 RP: sure Apr 11 11:49:49 nrossi: top patch of bitbake's master-next branch Apr 11 11:49:58 nrossi: can't see to get the webui to update :/ Apr 11 11:50:10 ah, here we are http://git.openembedded.org/bitbake/commit/?h=master-next&id=68759ec099a304c86341c801c5156554169e19dd Apr 11 11:50:49 RP: got it, testing now Apr 11 11:52:24 nrossi: also see https://bugzilla.yoctoproject.org/show_bug.cgi?id=11319 which is probably the same issue Apr 11 11:52:25 Bug 11319: normal, Medium+, 2.3 M4, rebecca.swee.fun.chang, NEW , "go" recipes trigger warnings/error messages for unrecognized MACHINEs. Apr 11 11:52:42 RP: Apart from the "except except", it removes the build_depends... but still getting "Error during finalise of ...bb" Apr 11 11:53:50 nrossi: siggen.py probably needs the same fix Apr 11 11:53:54 Yep that bug looks to be reporting the same issue. Apr 11 11:56:32 RP: yep, that does the trick Apr 11 11:59:35 RP: If I have DISTRO_FEATURES_remove = "x11" in my local.conf, it will get removed even if I try to add it in native_virtclass_handler() for native-sdk Apr 11 12:33:13 jku: how are you adding it? setVar("DISTRO_FEATURES") should clear any remove Apr 11 12:33:30 nrossi: care to send a patch to the bitbake list? Apr 11 12:34:48 RP: sure, just making sure it doesn't cause an odd "-sh: command: not found" when logging in on the system Apr 11 12:36:13 RP: the recursive "bitbake-diffsigs" fails to chase down the entire dependency chain because 'runtaskhashes' contains keys like /fast/work/openembedded-core/meta/recipes-devtools/go/go-cross_1.8.bb.do_prepare_recipe_sysroot Apr 11 12:36:51 pohly: I don't understand :/ Apr 11 12:36:58 nrossi: cool, thanks Apr 11 12:37:31 RP: hmm, I was hoping that this might ring a bell. Probably need to get hold of bluelightning after all. Never mind. Apr 11 12:38:21 It's annoying for developers using yocto-compat-layer because the output isn't as complete as it could be, instead depending on a human to split the key quoted above into pn + task. Apr 11 12:39:20 RP: Also quick question did you want me to send a patch for both the data.py and siggen.py changes? Apr 11 12:40:01 nrossi: one patch covering both is fine Apr 11 12:40:10 nrossi: since my patch was clearly broken :) Apr 11 12:40:19 RP: ok, will do. :) Apr 11 12:40:46 pohly: improving the sigs traversal has been on the todo list for a long time... Apr 11 12:46:57 RP: where do I need to add this dependency? Shouldn't that be the default? Apr 11 12:48:58 g0hl1n: I don't remember offhand how linux-yocto is structured so I don't know Apr 11 12:49:39 RP: regarding inheriting multiconf again: suppose it is done properly and set differently by two distros. Should that really influence gnu-config-native? After thinking a bit more about it, that part still seems a bit fishy to me. Apr 11 12:50:36 pohly: I doubt we'd ever be able to guarantee native checksums don't change between distros Apr 11 12:50:36 jku's "Use fixed DISTRO_FEATURES for native" tries to remove such dependencies, but I don't think it covers MCPREFIX, does it? Apr 11 12:50:49 Ah, okay. Apr 11 12:51:05 RP: The login issue i mentioned above is not related to the skip changes, appears that this commit introduced a dep on the shell built-in "command" -> e77cdb761169e404556487ac650dc562000da406 Apr 11 12:51:07 pohly: jku's work removes some of the delta which helps significantly even for our testing Apr 11 12:51:33 nrossi: hmm, I wondered about that and then decided to take it on trust Apr 11 12:51:53 RP: something definitely still removes "x11" after d.setVar("DISTRO_FEATURES", ..) Apr 11 12:51:55 https://pastebin.com/R4YTcSsd Apr 11 12:51:56 RP: maybe enable 'command' in busybox? if thats available Apr 11 12:52:08 nrossi: yes, perhaps Apr 11 12:52:19 I was wondering, because the resulting tools end up using the same file paths (tmp/work/x86-64). So doing a multiconfig with two different distros active at the same time is not supported. Apr 11 12:52:26 RP: will have a look after i send the patch for the bitbake change Apr 11 12:52:29 jku: can I see the patch you're using? Apr 11 12:52:42 * zeddii_home pictures RP task swapping and spinning in circles at the moment Apr 11 12:52:51 nrossi: thanks. I can't cope with the regressions atm :( Apr 11 12:53:03 zeddii_home: I'm supposed to be having vacation this week too Apr 11 12:53:11 yeah I feel bad for contributing to this Apr 11 12:53:14 noooooo. that sucks. Apr 11 12:53:35 I had some linux-yocto -stable updates queued. but I’m going to sit on them for a while. nothing critical. Apr 11 12:53:35 zeddii_home: bad choice of dates, I've given up on that now Apr 11 12:53:40 ah ok. Apr 11 12:53:51 zeddii_home: please do send them as rc1 is due any time now Apr 11 12:54:09 ok. will do. it’ll be my last round for this release. Apr 11 12:54:09 RP: here also with my interpretation of what you wanted for nativesdk http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=jku/native-and-nativesdk-distro-features Apr 11 12:54:52 jku: looks right :/ Apr 11 12:55:22 jku: what command did you use to generate that pastebin? Apr 11 12:56:17 "bitbake -e gtk-doc-native | less" and copy paste the relevant bit Apr 11 12:56:32 jku: so the native version broke Apr 11 12:56:51 I think it maybe was that way all the time Apr 11 12:57:23 jku: its not behaving like I thought it would :/ Apr 11 12:57:26 I just didn't try DISTRO_FEATURES_remove with my earlier patches, only _append Apr 11 12:58:55 jku: I think you found a bitbake bug Apr 11 13:02:33 jku: try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=ded787264668042981bc47e822fc745a8202c635 Apr 11 13:03:17 jku: we probably need to write a test for that too. Such a change does make me a little nervous at this point in release... Apr 11 13:04:47 RP: yep that looks like I expected Apr 11 13:06:04 jku: cool. I wonder what it breaks... Apr 11 13:09:49 jku: I'll put this in the next round of testing Apr 11 13:10:02 jku: it doesn't seem to change build checksums at least which is a good sign Apr 11 13:11:07 jku: I added a testcase and sent it out Apr 11 13:11:26 ok. I'll have one full test build and send v3 Apr 11 13:38:59 RP: FYI, I'm still chasing which of the different -cross need the TARGET_ARCH[vardepvalue] line. Apr 11 13:43:37 pohly: Is it proving a pain to find them? :/ Apr 11 13:45:51 If I want a full-screen webbrowser (no buttons or url interface) on a touch device without X, what would be the path (of least resistance) in Yocto? Apr 11 13:46:02 The bitbake-diffsig recursion issue meant that I was doing a lot of cut-and-pasting to get to the actual sigdata file. I've now changed yocto-compat-layer.py to produce a better list of tasks to look at. Apr 11 13:46:40 What remains is a DEFAULTTUNE dependency in go-cross which seems related to GOARM. Apr 11 13:47:10 I already have TARGET_ARCH[vardepvalue] = "${TARGET_ARCH}" in go-cross.inc, but that's not enough. Apr 11 13:48:34 go-cross-powerpc64/1.8-r0.do_configure.sigdata: https://pastebin.com/ij1kUuu4 Apr 11 13:48:49 I'm still not very good at chasing variable dependencies :-/ Apr 11 13:49:36 pohly: TARGET_GOARM[vardepvalue] = "${TARGET_GOARM}" maybe? Apr 11 13:49:55 export GOARM = "${TARGET_GOARM}" Apr 11 13:50:08 From go.inc Apr 11 13:50:18 Yes, probably. Apr 11 13:51:37 pohly: that does sound like it makes go depend on a specific arm platform rather than be one go for all arm arches Apr 11 13:51:57 pohly: is GOARM needed on non-arm platforms? Apr 11 13:52:45 I don't know what that does. Apr 11 13:54:17 pohly: its a little worrying... Apr 11 13:56:14 RP: I agree, so I'll probably leave that unchanged and open for further discussion. Apr 11 13:56:52 RP: so regarding the regression issue of getting "command: not found" during /etc/profile. Turns out "command" can be a built-in for busybox (ASH_CMDCMD), but not all shells have it (tcsh/csh dont). But it is in the POSIX 2008 standard :| (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html). Opinions on whether the /etc/profile should be Apr 11 13:56:52 allowed to use 'command' or not? Apr 11 14:01:47 nrossi: I suspect we should probably use it if its POSIX Apr 11 14:01:57 nrossi: open to other opinions though Apr 11 14:02:21 RP: ok, will send out a patch that enables CMDCMD in busybox and see if anyone has comments. Apr 11 14:03:08 nrossi: thanks Apr 11 14:03:37 Saur: ^^^ Apr 11 14:05:11 RP: Well, I am obviously for using command. ;) Apr 11 14:11:57 Saur: obviously Apr 11 14:12:33 Saur: I'm just a little sad we're getting these regressions as regressions are eating a ton of my time :( Apr 11 14:15:10 RP: Well, one thing with OE that is lacking is that there is no way of setting dependencies for individual tools that may or may not be provided by busybox. We have had a lot of problems relating to this where scripts from OE e.g., assumes that awk is available on target, but where our busybox configuration has it disabled. Apr 11 14:17:25 RP: In this case I actually got the suggested code change from our shell expert, who obviously is an expert on bash/dash and POSIX, and not tcsh/csh... Apr 11 14:26:52 Saur: I have to warn you that each time your patches regress the builds, the less likely I become to quickly merge patches :/ Apr 11 14:31:55 RP: Understandable. At the same time the code was broken before my change so something had to be done. In retrospect though, I definitely should have check the default busybox configuration, and not just assumed that CONFIG_ASH_CMDCMD was enabled. :( Apr 11 14:33:54 RP: But I definitely want a way to have dependencies on commands provided by busybox (or any alternatives) so that this kind of problem can be avoided (assuming that the correct set of dependencies are added). Apr 11 14:35:04 RP: And I am truly sorry for having introduced a regression. :( Apr 11 14:43:23 Saur: I agree a way to handle the configuration problem would be nice. I don't currently know how we could do it though Apr 11 14:46:06 RP: Btw, and totally unrelated, have you seen this ticket: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11124 I reported a way back (someone seems to have set the target milestone far off)? When it triggers it causes serious trouble, typically requiring to wipe tmp. Apr 11 14:46:07 Bug 11124: critical, Medium+, 2.3 M4, maxin.john, NEW , Problem with RSS and functions that modifies files installed into RSS by other recipes Apr 11 14:47:04 Hmm, apparently yocti's take on the target milestone is better than what I see when I look at it in my browser... Apr 11 14:48:26 Saur: my webbrowser agrees with yocti Apr 11 14:48:51 Saur: You might want to flag this on the list with the mail I sent earlier about M4 rc1 blockers if you think this should be fixed Apr 11 14:49:01 Saur: I'm trying to get a definitive list of what we need to do together Apr 11 14:49:18 RP: Ok. Which list? Apr 11 14:49:22 Saur: oe-core Apr 11 14:49:41 RP: Ok, I see it. Apr 11 14:49:54 Saur: I agree the above is a problem, equally, I've already cancelled my vacation this week and am working to try and sort things out yet am drowning. So will it get fixed? Don't know. Apr 11 14:51:05 RP: Just let me say that we really appreciate the work you do. Apr 11 14:53:00 Saur: thanks. I sometimes wonder why I do it :) Apr 11 14:53:04 RP: I have some ideas on how it could be solved, but I have not had time to look at it myself. We just switched to Morty yesterday, and I have spent a lot of time the last month just building with both Morty (for our upgrade) and Pyro (to be able to use it once it is released) to weed out all the problems we have with either... Apr 11 14:54:06 RP: The question is if it is enough to solve it for the particular problem of passwd/group or if it has to be solved generically. The former is, obviously, much easier... Apr 11 14:56:51 RP: My idea is to let all packages install a file in the sysroot with the useradd & co commands instead of modifying the passwd/group files, and then have a post function that takes all these files and runs them to generate the real passwd/group files. Apr 11 14:57:26 That way if any package is added/removed/modified, the resulting passwd/group files would still be correct. Apr 11 14:58:10 Saur: I agree, I did even start to write something like that, just never finished Apr 11 14:58:30 RP: Do you still have it around (to use as a starting point)? Apr 11 14:59:38 Saur: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=3ea25350e3a233184a654fe74e152d9d09f3c773 was my starting point Apr 11 15:01:28 RP: Ok, good. I will see if I can work some on this. But I will reply to your mail just to get it on record. Apr 11 16:19:51 RP: GOARM is specific to ARM arch it is a noop on others Apr 11 16:24:26 however this has to know difference between arm subarches eg. v7 and pre-v7 Apr 11 16:35:16 khem: we should probably only export that for arm then Apr 11 16:35:22 khem: make this clearer Apr 11 16:39:38 I just searched the mailing list, anyone else seeing subversion native die on a missing serf.h header ? I swear this was recently talked about, but can’t find it. Apr 11 17:03:08 nrossi: Are there any clock settings in the meta-xilinx layer? Apr 11 17:03:47 JoiF: what sort of clock settings are you referring to? Apr 11 17:04:04 The main system clock/oscillator Apr 11 17:04:24 JoiF: which board? Apr 11 17:04:38 So I'm running on my custom board, which is based on the Zybo Apr 11 17:05:09 In vivado, I had to change its default main-clock setting from 50MHz to 33.33MHz Apr 11 17:05:35 Just wondering if there's something similar I have to do for the Yocto build Apr 11 17:05:41 JoiF: that change will mean a number of minor changes in u-boot and kernel device trees Apr 11 17:06:19 JoiF: also you will likely need to provide custom ps7_init files Apr 11 17:06:44 So is the layer assuming 50MHz? Apr 11 17:07:25 JoiF: the layer doesn't, just all the components (u-boot, kernel) are assuming that you are using a Zybo (exact zybo) Apr 11 17:09:46 JoiF: since you board is no longer equivalent to a zybo, you will probably need to create a custom machine setup, and then make changes to u-boot and the kernel device tree Apr 11 17:11:42 zeddii_home: I have seen that before but I won't remember why :/ Apr 11 17:12:11 the header file is in include/serf-1/serf.h in my native recipe specific sysroot. Apr 11 17:12:19 but I see no where that serf-1 is on the include path. Apr 11 17:12:30 it does have a pkgconfig setting for serf, so I’m in a devshell poking at that now. Apr 11 17:13:41 odd: Apr 11 17:13:42 pkg-config --cflags serf-1 Apr 11 17:13:43 -I/home/bruce/overc-project/tmp/sysroots/x86_64-linux/usr/include/serf-1 -I/home/bruce/overc-project/tmp/work/x86_64-linux/subversion-native/1.9.5-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include Apr 11 17:13:48 one has serf-1, one doesn't Apr 11 17:13:55 the one with out it, is where the header actuall sits. Apr 11 17:13:58 * zeddii_home ponders Apr 11 17:17:37 nrossi: I think I see a potential reason for my problem. Apr 11 17:17:43 nrossi: Do you have a Zybo board? Apr 11 17:17:54 JoiF: I do Apr 11 17:18:23 nrossi: Can you see what frequecy its crystal is? Apr 11 17:18:55 nrossi: The Digilent schematics don't specify. And I think my schematics guy pulled a number out of his ass.. Apr 11 17:19:58 JoiF: ahh so X1 is not populated Apr 11 17:20:35 nrossi: On the Zybo? Apr 11 17:21:01 JoiF: yer, checking the schematics now for the psclk source Apr 11 17:22:16 nrossi: DSC1121CE5-50.0000 Apr 11 17:22:33 JoiF: Yep, its a IC22, not the X1 source Apr 11 17:24:59 JoiF: Yep its definitely a 50M clock source Apr 11 17:25:30 nrossi: Which makes sense, because I was able to resolve my baudrate problems when I ran Vivado+SDK with a barebones application and changed the frequency from 50MHz down to 33.33 and resynthesized my bitstream. I thought it was just a default setting in Vivado, and had nothing to do with reality. Apr 11 17:27:15 nrossi: Nice. I hope he didn't order a re-spin of the board before he went to easter-vacation (there were other errors as well). I'll have him change it to 50MHz. Apr 11 17:28:17 JoiF: the zedboard and zc702 use 33.3333MHz so you can always just update the configs to get it working Apr 11 17:29:16 Yes. And that's probably where he got this number from. Apr 11 17:31:24 And to take some of the blame myself .. I've been using the zc702 up until now, so that's probably why the 33.33 MHz didn't strike me as odd when I reviewed the schematics. :/ Apr 11 17:35:50 nrossi: Thanks for your help! Apr 11 18:34:34 paulbarker, Renewed. The automated renewal stalled on a needed update. Apr 11 18:43:32 hi, if i create a project in toaster, and need to run bitbake for individual recipes after creation (i.e. in this case bitbake -c do_cleanall gettext-native due to a patch being applied), can i run something like poky/oe-init-build-env to get the environment setup correctly? Apr 11 18:44:29 if i just do 'source poky/oe-init-build-env' it puts me at ./build, which isn't right. if i do source poky/oe-init-build-env ./build-toaster-2, the environment doesn't match the project im working with in toaster Apr 11 19:47:04 is this all you can do? update orm_task set task_executed = 0 where recipe_id = (select id from orm_recipe where name = 'gettext-native'); Apr 11 19:47:24 and remove the work dir Apr 11 19:52:25 gah, a greedy exception handler is swallowing the *real* error i must have introduced, resulting in bitbake exiting with an error and no output Apr 11 19:52:38 no way to diagnose short of manuallyer viewing every line i've changed to check for potential errors Apr 11 19:58:07 lovely, it says there was an error message, but it was never displayed Apr 11 20:18:39 kergoth: :( Apr 11 20:25:49 kergoth: did that setvar _remove change look ok to you? Apr 11 20:25:57 kergoth: seems worrying its been missed so far Apr 11 20:29:48 RP: yeah, looks fine. and agreed Apr 11 20:32:51 * kergoth ponders Apr 11 20:38:24 kergoth: I threw in a testcase so we spot if we change behaviour again at least... Apr 11 20:38:49 saw that, good to see, still strange it wasn't noticed, but it wouldn't be the first time something like that has happened :0 Apr 11 20:43:03 kergoth: indeed. Some of the things like this that escape amaze me Apr 11 20:45:20 it's moments like that when i'm amazed anything manages to work at all :) Apr 11 20:45:32 but that's the case with most projects at one time or another Apr 11 20:48:20 kergoth: right, it is amazing it ever works :) Apr 11 20:49:56 and imagine this code runs in airplanes and trains and we are still alive :) Apr 11 20:50:52 khem: I remember learning about page tables and kernel mm pieces and thinking about that Apr 11 23:11:51 I'm having issues building meta-java on morty. I get the following: meta-java/recipes-core/jikes/jikes_1.22.bb:12: Could not inherit file classes/relative_symlinks.bbclass Apr 11 23:12:46 It seems that the meta-java master is not compatible with morty? Apr 11 23:13:23 The class it's looking for is in yocto master, but not the morty branch Apr 11 23:17:19 ah i figured out the issue. my build host system has debian's hardening-wrapper enabled by default per /etc/hardening-wrapper.conf, which is adding -Werror=format-security to everything regardless of the settings in openembedded-core/meta/conf/distro/include/security_flags.inc. i fixed gettext with a patch sitting in patchwork, but then gcc failed with the same thing which got me looking deeper. Apr 11 23:22:11 m4t: can you not just append -Wno-error=format-security, or does it add it at the end of the commandline? Apr 11 23:24:45 kergoth: didn't try that, i was doing it like the other overrides which just removed it and set that variable to "". but that didn't seem to work. Apr 11 23:25:09 i've just modified my env init script to unset that and a couple other perl env variables which could be troublesome. trying a fresh build now. Apr 11 23:25:58 when i said unset that i actually meant *set* DEB_BUILD_HARDENING=0 to override the /etc/hardening-wrapper.conf Apr 11 23:26:21 seems to work per a quick test with "gcc -Q -v" Apr 11 23:34:21 kergoth: but to answer your question, i just took a look and hardening-wrapper appears to add the extra parameters at the beginning of the command line, not the end. right after '^gcc '. Apr 11 23:53:07 lolsborn: it seems you might be mixing two incompatible releases for meta-java and oe-core Apr 11 23:54:01 m4t: that should only be affecting native packages I believe Apr 11 23:54:47 I'm not sure how the meta-java repo is versioned Apr 11 23:54:54 there are no branches Apr 11 23:57:06 there really ought to be :( Apr 11 23:57:24 you could poke the layer maintainers Apr 11 23:58:01 lolsborn: it seems that repo expects master to work for all releases after dora Apr 11 23:58:15 which is pretty much all supported released at this time Apr 11 23:58:23 so it seems to be a bug to me here Apr 11 23:59:20 It seems like a number of people are using a particular 'known good' version for their particular build :-( https://www.toradex.com/community/questions/3706/creating-image-with-java.html Apr 12 00:04:49 khem: yes that's as far as i've gotten. even after setting DEB_BUILD_HARDENING=0 before running bitbake, i want to say that env variable is dropped somehow by the time host gcc is called. with that set to 0 and hardening-wrapper still installed, the builds continued to fail with Werror=format-string. i uninstalled the hardening-wrapper package and the build succeeded. not sure what's going on there... Apr 12 00:05:50 DEB_BUILD_HARDENING=0 is when you are using debian build system to do builds which OE doesnt Apr 12 00:06:38 it affects standalone calls to 'gcc' as well, from what i can tell. since gcc is just a symlink to hardening-wrapper on the host filesystem, it affects anything that uses gcc. Apr 12 00:07:23 hmm IIRC we called out to /usr/bin/gcc directly but you are saying thats a wrapper ? Apr 12 00:07:40 yes debian/ubuntu uses dpkg-divert and moves it to gcc.real or similar Apr 12 00:07:55 (only with the hardening-wrapper package installed) Apr 12 00:08:10 hmm, why cant they harden the toolchain default options Apr 12 00:08:13 like gentoo Apr 12 00:08:32 in anycase, we should try to fix these packages Apr 12 00:08:39 once for all Apr 12 00:08:56 instead of bypassing these compiler options IMO Apr 12 00:09:21 there are 2 patches in the patchwork queue that fixes gettext Apr 12 00:09:37 but yeah it's more than just that apparently.. Apr 12 00:10:07 https://patchwork.openembedded.org/patch/137322/ and https://patchwork.openembedded.org/patch/137323/ Apr 12 00:12:04 btw khem this is what hardening-wrapper does when it's installed, if you're curious: https://pastebin.com/4TLrV6UW Apr 12 00:13:56 yeah no worries I got the idea how its working Apr 12 00:14:28 but one could modify gcc defaults to enable certain options by default Apr 12 00:14:33 yep Apr 12 00:14:36 which they dont seem to have done Apr 12 00:20:25 i was able to get it working with the wrapper installed and enabled by adding this to /etc/hardening-wrapper.conf: DEB_BUILD_HARDENING_FORMAT=0. so ssp etc is still there but just not the -Werror=format-string. Apr 12 00:21:01 i guess bitbake strips environmental variables at some point before gcc is called? that'd explain why it was still failing before Apr 12 00:41:01 yes it flushes defaults Apr 12 00:41:20 you can add them to whitelist Apr 12 01:01:19 ah, thanks. i'll look into that. **** ENDING LOGGING AT Wed Apr 12 03:00:01 2017