**** BEGIN LOGGING AT Wed Apr 12 03:00:02 2017 Apr 12 05:52:59 I would like to have two different toochains for different architectures available and build selected recipies using this specific toolchain. What is the best/proposed way to do this? Apr 12 06:01:15 piotr_: inside a single build, you mean? Apr 12 06:07:09 yes Apr 12 06:07:38 i have a special SoC, which has 3 CPUs, dual A9 and CM3 Apr 12 06:07:48 piotr_: care to explain the usecase a bit? like, compiling and bundling in firmware? Apr 12 06:08:05 ah well a9 and cm3 are no different arches, but only tunes :-) Apr 12 06:08:50 the default tune is cortexa9, so the SDK and apps are build using this tune Apr 12 06:09:06 except maybe if the cm3 need none-eabi, hmmm. Apr 12 06:09:28 in my case what i need to do is to build a CM3 SW, and include the binary in the A9 rootfs Apr 12 06:10:08 and i would like to build it using one command, like bitbake my-image Apr 12 06:10:36 and at the same time i would like to have an sdk from CM3 Apr 12 06:11:05 i see. my first idea would be to see if you can leverage something from http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr Apr 12 06:11:47 because thats basically what you just described: building firmware (in that case, zephyr) for some simpler SoC Apr 12 06:12:08 the rest should be just packageing and dependencies in my understanding Apr 12 06:21:53 hmm, maybe i could just change the default tunes for the CM3 recipe? Apr 12 06:22:27 and add dependency to the new cross compiler just like it is done in zephyr? Apr 12 06:23:05 piotr_: i don't know the inner workings all too well, sorry. it was just my first thought. Apr 12 07:00:46 If I want to submit a patch to poky. What's the official way? Is this guide valid? https://wiki.yoctoproject.org/wiki/Poky_Contributions Apr 12 07:04:00 Tamis: you don't submit to poky, you will need to submit to one of the sub-projects (bitbake, oe-core, meta-yocto) Apr 12 07:04:46 (well they are not sub-projects, but poky is just a git repo which is a merge of those three projects) Apr 12 07:10:59 nrossi: ok I think I found it. I have to submit oe-core Apr 12 07:12:09 nrossi: Thanks a lot. I will search of how to do it there, first. Apr 12 07:13:52 Tamis: There is a nice wiki page that describes how to go about it http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Apr 12 07:14:19 nrossi: did you manage to send that patch? I have someone else with that issue :/ Apr 12 07:14:40 RP: i sent both out yesterday, even Cc'd you on both :) Apr 12 07:15:08 nrossi: Thanks a lot again! Apr 12 07:15:45 RP: bitbake one -> https://patchwork.openembedded.org/patch/139031/ Apr 12 07:16:08 RP: oe busybox one -> https://patchwork.openembedded.org/patch/139036/ Apr 12 07:16:57 nrossi: I'm pleased I asked as I have no record of these in my email :/ Apr 12 07:17:55 RP: hmm odd, they didn't get put in your spam folder ? Apr 12 07:20:45 nrossi: literally no mention of these even in my mail logs on the server :/ Apr 12 07:22:02 RP: let me send you an email directly, let me know if you get it. Apr 12 07:30:21 nrossi: I can see if on my mail server but its deferred, not sure why. Something isn't right :( Apr 12 07:32:17 RP: sounds odd, if you get any more info let me know. If it matters I am using gmail for smtp Apr 12 08:07:57 nrossi: it did come through in the end, unlike these list emails which I can't find Apr 12 08:25:51 Hi, is there a way to detect recipes which have do_compile[noexec] = "1"? I run some static analysis tools over all recipes in our build and would like to skip all which don't have a do_compile task. grepping 'bitbake -e' output for every recipe feels a bit wrong.. Apr 12 11:02:42 I modified a dtsi and I'm trying to do a rebuild.. Apr 12 11:02:47 But it won't :/ Apr 12 11:09:03 So I'm wondering what I need to "touch" or do to make it rebuild? Apr 12 11:46:44 JoiF: you modified source code in workdir? "bitbake -C compile " will invalidate the compile stamp and run default task Apr 12 11:48:42 ah "dtsi". I should really start reading whole lines. That was the 3rd time responding without reading the whole thing today... Apr 12 11:52:17 is this really the cleanest oneliner for this purpose: Apr 12 11:52:20 EXTRA_OECONF_append_class-target = "${@['', ' --disable-gettext '][(d.getVar('USE_NLS') == 'no')]}" Apr 12 11:52:48 I'd like to do pretty much that but that line makes my head hurt Apr 12 11:59:40 jku: ${@ ' --disable-gettext ' if d.getVar('USE_NLS') == 'no' else '--enable-gettext' } Apr 12 12:00:15 Or empty string instead of --enable-gettext, as in your array. Apr 12 12:00:58 pohly: thanks, that looks much more reasonable Apr 12 12:01:49 I think the array trick pre-dates the if ... else construct in Python. Apr 12 12:20:56 what would you recommend as a beginners guide to yocto? Apr 12 12:21:17 phako[m]: the yocto quick start :) Apr 12 12:21:19 phako[m]: https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html Apr 12 12:22:30 ah Apr 12 12:22:31 thx Apr 12 13:07:01 if I want to compile a device tree for a dev board, do I need to use a dtc specifically for that board or can I use any? Apr 12 13:14:35 jku: Can I squash http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=73173211f1a53d3fea18dbd93a3254dae203e893 into your nativesdk distro_features change? Apr 12 13:16:23 RP: sure Apr 12 13:16:42 jku: that fixed issues the AB tests identified Apr 12 13:20:59 RP: out of interest, what was the issue that needs libc-locales et al? Apr 12 13:21:38 or is that just because it's sensible Apr 12 13:23:17 jku: nativesdk-glibc-locales won't build without it Apr 12 14:02:47 pohly: why the long list of hardcoded tasks in the compat script? Apr 12 14:03:06 RP: because determining them at runtime is harder. Apr 12 14:03:17 pohly: why do we need a list at all? Apr 12 14:04:29 So that the tool knows that it should look at do_fetch before do_compile when both have signature differences, and then can prune do_compile entirely if the machine tuples are the same. Apr 12 14:04:51 In other words, start looking for a relevant difference at the start of building a recipe. Apr 12 14:05:58 pohly: I don't like having a hardcoded list like this at all, especially if it encodes relationships between the tasks :( Apr 12 14:07:12 RP: it's not crucial to have the list absolutely correct. If a task isn't found or the order is slightly off, then it just won't pick the best task to look at. Apr 12 14:08:00 The alternative is to pick one machine, generate the depgraph, and derive the current list from that. Doable. Apr 12 14:08:41 pohly: I think that sounds better, I have a very strong dislike of maintaining two sets of the same information Apr 12 14:09:03 Can we treat that as an enhancement for 2.4 in Bugzilla, with me as owner so that we don't forget? Apr 12 14:09:25 pohly: We can certainly do that but I don't think I can take the current patch Apr 12 14:09:57 Can you take it without the hard-coded list? Apr 12 14:11:07 pohly: yes Apr 12 14:11:53 pohly: signature change stuff looks good, passed the tests and is merged btw, thanks Apr 12 14:11:54 I can see how much work it is to create the list dynamically. What's my deadline for such a patch (besides me "going on vacation on Friday")? If I don't get it done, plan B is to fall back to sorting alphabetically (not very developer friendly, but better than nothing). Apr 12 14:12:21 pohly: it depends how long it takes to get the fixes for runqemu really Apr 12 14:52:30 RP: "fixes for runqemu" = running in commands via serial console fails? That's that I'm currently seeing. Apr 12 14:52:40 in oe-selftest Apr 12 14:53:19 pohly: in which branch? Apr 12 14:54:05 ed2: master from yesterday Apr 12 14:54:18 I haven't looked at it in detail. Apr 12 14:54:31 pohly: I'll check it out. I'm working on it anyway. Apr 12 14:54:41 For me, it' Apr 12 14:55:11 pohly: any details on how exactly it breaks? Apr 12 14:55:55 run_serial fails to execute a command, leading to: Apr 12 14:55:55 AssertionError: 1 != 0 : Failed to run command "findmnt / --output SOURCE --noheadings": Apr 12 14:55:55 t Apr 12 14:56:04 Apparently "t" is the output that it got. Apr 12 14:56:45 I also have the "command: not found" error when logging in manually. Perhaps that's it. Apr 12 14:57:24 Is that fixed in current master(-next)? RP pointed it out on the list, at least, so it is a known issue. Apr 12 14:57:56 Either way, I need to update before investigating. Apr 12 15:01:34 I looked at runqemu code today. it looks like when runqemu runs from bitbake, it still tries to use global sysroot. I don't know how does it work at all. Apr 12 15:22:02 Saur: Any idea on timescales on the useradd issue? I'm getting a bit worried about when I can run the release build as this is looking like the blocker :/ Apr 12 15:24:48 RP: I worked on it all through the night, and made some progress. But I still have a hard time to untangle all combinations of prepare_recipe_sysroot, populate_sysroot, various setscene tasks, etc... Apr 12 15:25:01 RP: FYI, I'm about to send a revised patch series with the task list determined dynamically. Apr 12 15:26:50 RP: There is code in useradd_sysroot_sstate() to create a ${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN} file. I tried to create that as ${SYSROOT_DESTDIR}${bindir}/postinst-useradd-${PN} from SYSROOT_PREPROCESS_FUNCS instead and that improved things a little. Then I had to get an hour of sleep... Apr 12 15:30:57 RP: I have pushed what I have to pkj/fix_useradd on git@git.yoctoproject.org:poky-contrib Apr 12 15:31:38 RP: I split your commit in two since I really liked what you did with useradd.py regardless of the other matter. Apr 12 15:32:47 RP: I have fixed some minor problems and renamed the two split_ functions to give them more appropriate names. Apr 12 15:33:17 Saur: makes sense, you can see where I was going with it Apr 12 15:36:05 RP: Not really, actually. :) To me, having a postinst-useradd-${PN} file in the sysroot for all recipes that add users/groups and running them after copying ${datadir}/base-passwd/passwd.master to ${sysconfdir} should do the trick, as long as it is done in all possible situations where the sysroot is setup... Apr 12 15:39:23 Saur: hmm, I'm just looking at this all again and I think I'm misremembering details :/ Apr 12 15:39:54 Saur: I'll spend a few minutes on this, see if I can get anywhere Apr 12 15:40:19 Saur: I'd forgotten that useradd now creates those postinst files Apr 12 15:40:21 Please do, I will not have any time to work on it today anyway. Apr 12 15:40:33 Saur: having those available helps a lot Apr 12 15:41:14 RP: But I have not been able to see them being used, at least not until I added my code to create them in ${SYSROOT_DESTDIR} instead of ${RECIPE_SYSROOT}... Apr 12 15:43:27 RP: Btw, another thing. AFAICT, with the current implementation, users/groups created in a dependency are never being made available in the sysroot for the recipe with the dependencies. This is a change compared to before. However, personally I like it as I think each recipe should be responsible for creating all users/groups it needs, but others may disagree. Anyway you need to decide whether this is how it should be or not... Apr 12 15:45:52 Saur: your change looks right. How this works at all I'm also not sure :/ Apr 12 15:46:30 RP: Well, that's kinda the problem. It doesn't work as it was. ;) Apr 12 15:47:55 RP: But even with my change, things are not working as I expect them to. I can see the postinst function of a recipe I depend on being run, but still the users it creates do not appear in the passwd file of my sysroot... Apr 12 15:49:06 RP: Unfortunately I have to run now to drive my son to floorball practice. Apr 12 15:49:57 RP: But if you make any more findings, keep me posted. Apr 12 15:56:46 Saur: will do Apr 12 16:50:32 Say recipe A creates a user and recipe B depends on A. We can make recipe B create recipe A's users in it sysroot but we need the useradd tools. We don't want to have to markup up every recipe which indirectly depends on a recipe which uses adduser. So how do we solve this in an RSS world? :( Apr 12 16:50:43 Saur: ^^^ Apr 12 16:51:57 Doesn't recipe B have a depednency on the useradd tools? Apr 12 16:54:55 fray: no, why would it? Apr 12 16:55:17 fray: A does the user creation and B may or may not care about that Apr 12 16:55:36 Sorry then A.. Apr 12 16:55:47 If B requires A, and A has to add a user.. then A needs a dependency on the useradd tooling Apr 12 16:56:02 fray: so the tools are in the RSS for A, however when we create the sysroot for B, we need the tools Apr 12 16:56:22 they are not in the RSS for B, nor is there a dependency to pull them in Apr 12 16:56:28 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7724 Apr 12 16:56:29 Bug 7724: major, Medium, 2.4 M1, leonardo.sandoval.gonzalez, NEW , useradd.bbclass users cannot be safely referred to by dependent recipes due to sstate-induced race with base-passwd Apr 12 16:57:29 The tools for adding users is small enough, why can't they be available to all RSS? Since we know that all RSS will need at least minimal users being created (base-files), if not more. Apr 12 16:58:08 Dependency inheritance of certain types is really needed for these types of host tools that are not generally available otherwise Apr 12 16:58:14 fray: there is no such mechanism and you'd have to remove circular dependencies Apr 12 16:58:34 fray: the dependency chain turns out not to be so small either iirc Apr 12 16:59:06 I realize there is no mechanism -- but requiring Package A, that has a need for some tool as part of a postinstall script.. is pretty standard behavior..... adduser of course is the most common that we have where this is needed, but it's a general problem elsewhere.. Apr 12 16:59:16 lsandov: indeed, I remember that. The patch I have may help fix things Apr 12 16:59:22 the alternative is that each package that uses a 'non-standard user' (not sure even how to define that) would need to have their own addusers.. Apr 12 16:59:38 this will cause a lot of extra overhead on the package install side Apr 12 16:59:58 fray: well, postinsts were meant to be used at all for these reasons in the rss/sstate context Apr 12 17:00:08 meant not to be Apr 12 17:00:41 then there has to be an alternative way (for rss) to setup users. The values are known, could they be put into an sstate-cache control file and inherited/executed that way Apr 12 17:04:56 fray: without writing our own script version of useradd I'm not sure how to do that Apr 12 17:05:20 Doesn't rss populate the items based ont he sstate-cache files? Apr 12 17:07:15 fray: it currently stores the same useradd commands as would get used on target or when creating the sysroot originally Apr 12 17:07:46 yes, but couldn't you store something that says "I need the useradd tooling... after installing that into the rss, now run this script'? Apr 12 17:08:21 then the adduser class can set whatever values are needed to write that special depednency into the sstate control file(s)... Apr 12 17:08:37 it does mean there will be a dependency that is not known at dep processing.. Apr 12 17:09:43 fray: and that is the problem, we can't have deps we don't know about Apr 12 17:10:04 I think I know how we can make a gross hack and avoid most problems Apr 12 17:10:04 in this case, what is the problem having a (native) dep that isn't know during early processing? Apr 12 17:10:32 since we know we have to install A to build B.. and A already will have a dep on the (native) useradd.. we can assume it exists Apr 12 17:12:39 fray: we can't since A may come from sstate and not have it deps extracted Apr 12 17:13:39 Either B has to inherit A's deps (on select items) or we have to make sure that the tool is always avaialble to be loaded.. Apr 12 17:13:45 I can't think of any other option Apr 12 17:14:23 fray: as I said, I think we can actually make this work in a reasonable way Apr 12 17:14:35 fray: only add users if the tools are available Apr 12 17:15:11 but if we don't add the users, then the resulting packages won't have the users in them and we've got non-deterministic behavior Apr 12 17:15:38 fray: packages don't matter here its about sysroots and the behaviour is entirely deterministic Apr 12 17:16:41 the package is generated from 'B' (which required A, which needed the adduser). How will 'B' do a chown if it doesn't have the users.. if it allows that to fail then we've got non-deterministic package gen Apr 12 17:27:50 fray: we make the assumption that B doesn't change ownerships to non-default users/groups unless it inherits useradd Apr 12 17:29:09 do we have a verification in insane on that? Apr 12 17:29:19 fray: not sure Apr 12 17:29:21 if you inherit useradd, but don't actually set any users -- I thought that errored Apr 12 17:29:49 fray: well, it would be enough to add a depends on the useradd/groupadd tools Apr 12 17:39:40 fray, Saur: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=1b192559734ae3718da79fd09568a2bb93cb879e Apr 12 17:43:29 I don't see anything obviously wrong with it. It should trigger faults if a package tries to chown w/o the user being there.. and also prevent implicit users/groups Apr 12 18:31:19 lsandov: care to try the above patch with that bug you mentioned? Apr 12 18:34:12 RP: sure, let me try it Apr 12 20:12:39 nrossi, Can I get your help troubleshooting an e-mail issue? Apr 12 20:13:21 nrossi, Could you forward me the original message, [PATCH] lib/bb/{data, siggen}: Don't warn on SkipRecipe exceptions, from your sent mail? Apr 12 20:13:57 nrossi, Forward to mhalstead@linuxfoundation.org if you could. Thank you! Apr 12 21:59:44 So I built a wandboard image based on Morty, and it appears that ALSA is hanging at startup. Apr 12 21:59:54 Not sure where to go from here. Any questions or suggestions appreciated. Apr 12 22:01:37 https://pastebin.com/bsTEtzi0 Apr 12 22:03:04 I say ALSA is hanging, but it could be the next thing in the boot process. Not sure what that might be. Apr 12 22:04:24 UBoot's bad CRC warning doesn't inspire much confidence either. Apr 12 22:08:06 So next step in the boot process should be mounting the file system. Apr 12 22:08:26 According to a working system compiled on Krogoth, anyhow. Apr 12 22:08:47 CRC warning is OK, run saveenv and it will go away Apr 12 22:09:36 Crofton|work: rgr, thanks. Apr 12 22:10:01 I don't have any ideas about the real problem :) Apr 12 22:10:12 lol, nuts. **** ENDING LOGGING AT Thu Apr 13 03:00:03 2017