**** BEGIN LOGGING AT Tue Jan 17 03:00:02 2017 Jan 17 06:42:34 May I know , how can one can get .so , I tried having PACKAGECONFIG_append_pn-qtbase = " sql-sqlite" in my local.conf but still I didn't see libqsqlite.so generated . Jan 17 08:34:02 is the yocto arm toolchain always called arm-poky-linux-gnueabi or can it have other names also? Jan 17 08:34:17 when targeting arm... Jan 17 08:48:20 Do I'm able to recompile individual driver modules on dev-shell the same way as I do with .dtb ? Jan 17 09:15:21 ^in-tree sources Jan 17 09:24:48 I think compiling only a single module is a bit tricky regardless of yocto Jan 17 09:25:58 Hi, iam still using the fido branch, but id like to update systemd to newer version. I would copy the systemd recipe from a newer branch. Is this reasonable? Or might i get in big trouble? Jan 17 09:28:39 I''ve tried make module.ko, but there is no makefile rule Jan 17 09:32:43 aV_V: I remember a rather long commandline with a bunch of variables... :-) Jan 17 09:33:30 fl0v0: something with as much system integration as systemd could be tricky... Jan 17 09:33:41 ernstp: do u have it on hand? :p Jan 17 09:59:22 fl0v0: that sounds like a great way to find all kinds of interesting new issues ... just as a statistic: There's 165 commits that mention systemd between fido and morty. Most of them are _not_ for systemd recipe itself -- you would at least want to skim through the list to see if there's anything you need there Jan 17 10:00:13 hm so i better dont do it :D Jan 17 10:00:55 i just wanted the OnFailure function in unit files Jan 17 10:01:17 but i guess thats not worth it Jan 17 10:50:17 hm Jan 17 10:50:51 joshuagl, RP: so the new cluster has a debian testing machine that the AB then fires warnings all over as it's not supported. usually they're just warnings, selftest makes them fatal. Jan 17 10:51:06 rburton: yeah, filed a bug a bit ago Jan 17 10:51:28 https://bugzilla.yoctoproject.org/show_bug.cgi?id=10933 Jan 17 10:51:31 Bug 10933: normal, Undecided, ---, benjamin.esquivel, NEW , None-validated host distro such as debian-testing results in oe-selftest failures Jan 17 10:52:03 rburton: right, I was saying to joshuagl that we should probably add the distro to the whitelist in selftest to avoid this, or disable that check Jan 17 10:54:04 aye, my preferred workaround is for the selftest buildset to forcibly set the distro whitelist to "" Jan 17 10:55:33 rburton: comment in the bug? :-) Jan 17 10:55:52 rburton: oh, the buildset. In that case best change component etc too Jan 17 10:58:57 kanavin: ed is suddenly (and correctly) failing checkuri and appears to be out of date. Jan 17 11:05:14 rburton: checkuri? Jan 17 11:06:12 ed21: https://autobuilder.yoctoproject.org/main/builders/nightly-checkuri Jan 17 11:06:18 runs -c checkuri world Jan 17 11:06:24 which basically says "is the SRC_URI fetchable" Jan 17 11:08:47 What is the process towards submiting a patch for meta-oe? The oe-core mailinglist? Patched against master? Jan 17 11:11:29 sveinse : http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Jan 17 11:11:35 sveinse: openembedded-devel@, not oe-core Jan 17 11:14:26 hello, anyone working with meta-swupdate? I fail to compile swupdate-image for beaglebone black on morty even though that is supposed to be supported Jan 17 11:14:52 RP: rburton: how to make a meta-recipe that builds bunch of native tools? adding this line: DEPENDS = "parted-native syslinux-native gptfdisk-native dosfstools-native mtools-native bmap-tools-native" didn't work for some reason. recipe is built, but the native tools are not in its native sysroot. Jan 17 11:15:53 thanks. I do have a problem with it thou. I don't have a X and gtk setup to test this receipe on, so I cannot test if it (still) works for that. Jan 17 11:24:23 RP: rburton: inherit native did the trick! Jan 17 11:26:18 patches to meta-oe is preferred against master? Jan 17 11:26:19 rburton: could you rebase mut and check I didn't miss anything please? Jan 17 11:26:20 ed2: adding those depends absolutely should work if you buil the recipe Jan 17 11:26:37 sveinse: must be against master, unless you're backporting from master to a stable release Jan 17 11:27:11 rburton: I built the recipe and it didn't work. I'm in rss branch. probably that's the reason. Jan 17 11:27:38 RP: did last night, a few slipped out. jaixunn's bitbake -S thing, a gitsm patch, and the gummiboot removal in yocto-bsp. Jan 17 11:27:53 RP: (bottom 3 commits of current mut) Jan 17 11:28:13 rburton: could you push it please? ;-) Jan 17 11:28:31 i did last night Jan 17 11:28:40 What is expected level of these patch emails? E.g. will they be reviewed and proposed upon, or is this a simple acceptance thing, like "this is rejected, fix it and come back" Jan 17 11:28:53 rburton: oh, I see, you added to it too :) Jan 17 11:29:07 RP: yeah, mut2 and mut3 became mut Jan 17 11:29:17 which promptly exploded on the AB with OOMs again Jan 17 11:29:38 rburton: thanks Jan 17 11:29:54 rburton: I figured there was a gummiboot one somewhere and I hadn't merged bitbake but I have now Jan 17 11:30:52 does meta-oe have any autobuilders that cycles throuh all recipes? Jan 17 11:31:01 joshuagl: did anything non-trivial go to the main ab recently? its OOMing a lot. Jan 17 11:31:19 sveinse: jama runs builds on his internal cluster but its not really that public Jan 17 11:32:14 rburton: define recent? not pushed any code changes there for a couple of weeks Jan 17 11:33:07 the updated uim recipe passed all internal tests, so I'm ready to move on with it Jan 17 11:33:34 sveinse: feel free to pastebin if you want a pre-list critique :) Jan 17 11:33:50 rburton: thanks, diff or all of it? Jan 17 11:33:56 all of it Jan 17 11:34:33 (does pastebin parse bb syntax?) Jan 17 11:35:41 rburton, https://bpaste.net/show/5f9c523275c1 Jan 17 11:36:32 this is on jethro, but changes to master are minute. I'm repatching them now Jan 17 11:37:29 you can just put uim-native into DEPENDS, bitbake will do the right thing when generating the native form and won't depend on itself Jan 17 11:37:55 are those patches really target specific? needless complication if they're not. Jan 17 11:37:55 ok, good Jan 17 11:38:22 PACKAGECONFIG[gtk] = "--without-gtk2 --with-gtk3,--without-gtk2 --without-gtk3,gtk+ gtk+3" <— why depend on gtk+ when you turn of gtk2 Jan 17 11:39:00 dunno, I don't know the gtk part of this package at all. This is inhereting the exiting recipe setup Jan 17 11:39:02 PACKAGECONFIG[emacs] = ",--disable-emacs," <— the trailing commas make me irrationally angry, and please use —enable-emacs explicitly Jan 17 11:39:09 well gtk+ is gtk2, and you turn that off Jan 17 11:39:14 so you dont need to depend on it Jan 17 11:39:26 CONFIGUREOPTS_remove_class-target = "--disable-silent-rules" <— why? Jan 17 11:40:03 also your PACKAGES has a gtk2 package but you can't ever build it Jan 17 11:40:17 so id either add a gtk2 option alongside gtk3, or remove the gtk2 package Jan 17 11:40:58 pkg_postinst_uim-gtk2.0() { Jan 17 11:40:58 gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules Jan 17 11:40:58 } Jan 17 11:41:05 rburton, I added the PACKAGECONFIG[emacs] without any positive config as a way to avoid using EXTRA_OECONF = "--disable-emacs \. It was proposed by nrossi a few hours ago... Jan 17 11:41:30 that postinst needs a way to bail on rootfs time Jan 17 11:42:11 sveinse: if you want to always disable emacs, just add it to EXTRA_OECONF Jan 17 11:42:15 a packageconfig implies a toggle Jan 17 11:42:26 --disable-silen-rules. Don't know. inherited from the existing setup Jan 17 11:42:45 allright I'll revert those EXTRA_OECONFs then Jan 17 11:42:55 in fact all of these postinsts need $D checks as they'll be failing amusingly on the host instead of gracefully Jan 17 11:43:01 does anyone here successfully use SWUpdate on their embedded devices? Jan 17 11:43:10 assuming that the latest speaker has the authority :P Jan 17 11:43:22 sveinse: never use a packageconfig to force something off, as someone can turn it on Jan 17 11:43:40 (as thats the point: its a toggle option) Jan 17 11:43:50 rburton: yeah, I just didn't know it was a bad advice Jan 17 11:44:25 remove the —disable-silent-rules, no logic in being target-specific and autotools.bbclass already passes that Jan 17 11:44:33 oh its a _remove_ Jan 17 11:44:37 that's just stupid Jan 17 11:44:44 if it works for native then it works for target Jan 17 11:45:12 also i'd look at what the do_install_append() is deleting, if anything, and either comment why its being removed or put it somewhere. Jan 17 11:46:45 fix the SRC_URI to use the new download location (https://github.com/uim/uim/releases) now that googlecode has shut down Jan 17 11:47:04 does the xft option really need libxt? thats positively archaic. Jan 17 11:47:34 dunno, we don't use X, so this part is completely untested by me Jan 17 11:47:35 your intltool dependency should probably be intltool-native Jan 17 11:48:13 Hello, I just placed PACKAGECONFIG_append_pn-qtbase = " sql-sqlite" into my local.conf file but I don't find libqsqlite.so generated in my rootfs Jan 17 11:48:15 rburton: what is tar.lz? :) Jan 17 11:48:40 rburton: I'll add ed update to my next batch if you don't mind? is it urgent? Jan 17 11:49:15 I guess lz is missing from some regex, and so is not recognized as a new version, that ought to be fixed too Jan 17 11:49:33 ah yes, didn't notice that Jan 17 11:49:39 thanks gnu! Jan 17 11:50:35 kanavin: no urgent rush, i'll file a quick bug for the lz thing Jan 17 11:51:28 rburton: do we provide lzip-native? Jan 17 11:51:43 yeah Jan 17 11:51:55 I haven't yet seen a recipe using it though Jan 17 11:51:59 we magically depend on lzip-native if we spot a .lz file Jan 17 11:52:05 for tarball extraction or otherwise Jan 17 11:52:11 i think we added it to the core/bitbake as something in meta-oe needed it Jan 17 11:52:22 hm Jan 17 11:52:28 lzip itself is in meta-oe Jan 17 11:52:43 curse you gnu Jan 17 11:52:50 gzip not cool enough for you Jan 17 11:53:09 rburton: or bzip2, or xzip Jan 17 11:54:09 rburton: what is preferred when dl from github, the tarball URLs or the git repo? Jan 17 11:54:42 sveinse: tarballs Jan 17 11:54:59 if they're proper tarballs and not auto-snapshots Jan 17 11:55:08 yeah the versioned tarball not the "source code" link Jan 17 11:55:35 as that's a generated tarball and whilst github claim it will never change, there's still doubt. the versioned link is a maintainer-generated tarball so is static. Jan 17 11:56:19 this one, right? https://github.com/uim/uim/releases/download/uim-1.8.6/uim-1.8.6.tar.bz2 Jan 17 11:56:28 yeah that looks right Jan 17 12:00:55 (interestingly github does not seem to publish shas to verify the contents other than downloading it yourself) Jan 17 12:03:45 rburton: what was the deal on CONFIGUREOPTS_remove_class-target = "--disable-silent-rules" ? Jan 17 12:11:03 seems madness Jan 17 12:11:14 i'd just delete it Jan 17 12:12:34 rburton: just checked the do_install_append(). seems uim has hardcoded installing to /usr/share/applications which in turn creates a QA issue Jan 17 12:12:58 its empty (with my current configure config at least) Jan 17 12:14:03 in which case use rmdir --ignore-fail-on-non-empty Jan 17 12:14:13 deletes the directory if its empty, doesn't if its not Jan 17 12:14:38 agreed Jan 17 12:19:19 no clue what to do with the libxt, but it is not mentioned even once in the code. So I'll take it away, but again, I don't have a suitable test-setup for this Jan 17 12:21:10 seebs: thanks for help, the code base in question is rpm4, and it may do something weird. It all works if I enter and leave the chroot in parent process when needed, so I'll leave it at that (still fails if I enter the chroot in parent and leave in child, but let's move on :) Jan 17 12:21:28 ah, it installs a /usr/share/applications/uim.desktop. Hmm, what to do with this. The previous author simply removed it... Jan 17 12:22:00 sveinse: i guess the easy solution is to put it in the same package that contains the binary it executes. Jan 17 12:23:35 ...which is not built since gtk is disabled... Argh! Jan 17 12:24:08 I don't know if I want to go any deeper in this sinkhole Jan 17 12:26:45 heh Jan 17 12:27:00 sigh, the desktop file shouldn't be installed if gtk is disabled Jan 17 12:27:37 choices: 1) patch upstream build to respect configure options 2) delete it always and hope for the best 3) respect packageconfig in do_install_append and remove if gtk is disabled Jan 17 12:27:41 right, so I can add the desktop file into the gtk package split, but I don't want it generating a uim-gtk if it has been disabled Jan 17 12:28:05 I like 3. 2 is the current thinking of the recipe Jan 17 12:29:28 So how do I add a conditional PACKAGECONFIG statement to do_install_append? Jan 17 12:30:04 if ${@bb.utils.contains('PACKAGECONFIG', 'udev', 'true', 'false', d)}; then Jan 17 12:30:21 that turns into if true or if false, depending on whether udev is in PACKAGECONFIG Jan 17 12:31:04 the alsa recipes have several full examples Jan 17 12:31:15 brilliant Jan 17 12:38:00 The recipe generates the package libuim0. It defines libuim-dev (without the 0). It is empty because everything that it wants is gobbled up with uim-dev package. So what should I do? Jan 17 12:38:28 as in where will users expect to have their -dev? libuim(0)-dev or uim-dev? Jan 17 12:38:35 is UIM a binary or a library? Jan 17 12:40:42 rburton: don't know what to say. by that I mean that we use it as a library, but it does have some bin tools installed as well. according to their own description: a framework :P Jan 17 12:41:21 library I think. It does not act on its own Jan 17 12:43:02 Hi Jan 17 12:44:03 looking into trying morty branch for genivi-development-platform and first issue I encounter is lack of this class: https://patchwork.openembedded.org/patch/123289/ Jan 17 12:44:26 seems the reason it was removed was that it's not used Jan 17 12:44:37 so if there is gdp using it, can it be added back? Jan 17 12:44:50 I think we seriously should consider something else for asian language input in our end-user application.. uim is mess Jan 17 12:50:55 zeenix: if gdp is the only layer making use of the class it makes more sense to include it in gdp Jan 17 12:51:23 generally classes like that go in core when multiple layers are carrying potentially diverging copies Jan 17 12:54:40 zeenix: presumably gdp includes sip-native then as that isn't in oe-core either. Jan 17 12:54:44 the class should be with the recipe Jan 17 12:55:35 ah, sip is part of meta-qt4. Jan 17 12:55:40 someone should submit the class there. Jan 17 13:00:11 heh, when working on someone elses recipe and it does not work the way it was written in the recipe, should one implement the way the recipe is intended to be or continue using it the way the packages are generated? The former is probably the author's intentions, the latter is everybody using the package assuming where they can find their package data... Jan 17 13:02:10 when I fix uim, I know that we will have to change our dependencies in our code as well, beacuse the anthy files have now been moved from uim to uim-anthy as per the original recipe intentions Jan 17 13:02:38 rburton: we use meta-qt5 and i don't think there is any *sip* there Jan 17 13:04:06 ok, uim_1.8.6.bb V2: https://bpaste.net/show/8324f044fc3f Jan 17 13:08:39 zeenix: so how do you use the sip class, as it adds a DEPENDS on sip-native? :) Jan 17 13:10:17 rburton: exactly Jan 17 13:12:24 sveinse: postinsts should abort if $D is set as they need to run on the host Jan 17 13:12:27 erm, target Jan 17 13:12:50 and i'd always apply the patches unless they really are specific to target builds and break native builds Jan 17 13:16:01 rburton: do you have an example for $D and postinst? Jan 17 13:16:32 if [ "$D"] ; then exit 1; fi Jan 17 13:16:40 the libuim-dev and uim-dev thing is still broken Jan 17 13:16:49 in a postinst, if $D is set then it is running on the host at rootfs time Jan 17 13:17:08 the invocations in the postinsts look a lot like they need to run on the target, so if $D is set, exit 1 Jan 17 13:17:39 also don't use absolute paths like that as /usr/bin may not be $bindir Jan 17 13:17:54 no, I'm not sure about that. The whole point of having uim-native is to compile those tools, afacs Jan 17 13:21:41 /usr/bin/uim-module-manager --register skk --path /etc/uim Jan 17 13:21:58 that isn't where the binaries from uim-native will end up Jan 17 13:22:16 its possible the building of uim-native is entirely pointless Jan 17 13:23:43 man I'm close to giving up this thing... I did fix the issue of building uim properly, and I as a gratetude I though I'd offer something back to the community by contributing them back. But this is far more convoluted than I'd hoped for! Jan 17 13:23:52 maxin: can you look at the busybox problem pb just mailed the list about? Jan 17 13:24:13 hooray for recipes that apparently nobody really uses :) Jan 17 13:24:43 * rburton is just pointing out all the problems this recipe has Jan 17 13:25:09 I am grateful rburton, don't get me wrong Jan 17 13:25:55 To go back, would it be probable that it would be accepted to just change the three lines that makes the recipe fail in the first place, only. Leaving it as crappy as it is today? Jan 17 13:27:33 the current iteration of the recipe is entirely fixes over the what is in the repo now, i'm just saying there are further fixes that could be done. if you don't want to spend more time on it, send it in as-is. Jan 17 13:29:50 rburton: yeah, I think I will. But one thing regards to the libuim-dev vs uim-dev. Where do you think dev should go? Jan 17 13:30:12 hey everyone.. im trying to create a recipe with devtools Jan 17 13:30:14 http://pastebin.com/CJBhYjrz Jan 17 13:30:22 the recipe says one thing, but it ends up elsewhere :( Jan 17 13:30:33 anyone could help me find out what im doing wrong? Jan 17 13:31:38 I think its somithing with the do_install function of my recipe Jan 17 13:31:43 sveinse: in $PN-dev Jan 17 13:39:09 jku: thought i'd have fun and make build-deps fatal. ERROR: lib64-gtk+3-3.22.5-r0 do_package_qa: QA Issue: lib64-gtk+3-dev rdepends on lib64-wayland-protocols, but it isn't a build dependency? [build-deps] Jan 17 13:42:35 joshuagl, RP, halstead: first person to reboot ubuntu1404 gets a cookier, it's OOMing everything on sight. i propose rebooting to solve. :) Jan 17 13:43:02 not a gift box from the COrnish food place? Jan 17 13:43:11 no, just a cookie Jan 17 13:43:14 we have some spare oreos Jan 17 13:44:34 lib64-wayland-protocols? Jan 17 13:44:42 rburton: this is my final contribution https://bpaste.net/show/ed99dcdcef0b Jan 17 13:44:48 oh i can pause the worker, yay Jan 17 13:45:08 jku: see the multlib nightly run on the AB. i think it just found an edge case :) Jan 17 13:45:22 rburton, I can reboot too. Sorry I didn't have time to look yesterday with the holiday. Jan 17 13:45:47 holiday? definitely no worry. Jan 17 13:45:56 i just paused it on the AB in case you wanted to look at it. Jan 17 13:45:57 jku: hej, kommer du till FOSDEM? Jan 17 13:46:03 or we just reboot it Jan 17 13:48:23 zeenix: not planning to Jan 17 13:49:09 goodbye rpmresolve Jan 17 13:49:29 dnf can do its job with 'repoquery --installed --queryformat 'Package: %{name} %{arch} %{version} %{sourcerpm}\nDependencies:\n%{requires}\nRecommendations:\n%{suggests}\n'' Jan 17 13:51:25 postinstall scripts run on the server is not run with set -x is it? Because I cannot find any log of it Jan 17 13:52:00 rburton, Reboot in progress. I don't know if it will fix the issue but worth a try. Hardware log show nothing. Jan 17 13:52:34 jku: oh ok :( Jan 17 13:52:52 thanks halstead Jan 17 13:52:54 halstead: thanks Jan 17 13:52:55 rburton, Should I add it back in and see if it continues? Or leave it offline for testing? Jan 17 13:53:12 halstead: can we leave it off until the current mut has finished :) Jan 17 14:06:21 I'm trying to stress the system to see if we can reproduce with simple tests. Let that go for awhile. Jan 17 14:11:44 hi all, I tried to build cusomt initramfs image (not bundles) so I define INITRAMFS_IMAGE varibale in my machine.conf Jan 17 14:12:04 my problem is that why INITRAMS_IMAGE force kernel rebuild Jan 17 14:12:12 it will increase build time Jan 17 14:12:19 as I have kernel already build Jan 17 14:24:37 success!! Jan 17 14:30:05 it seems that fetch stamp is deleted and therefor kernel is rebuild again Jan 17 14:30:10 using 14.0.1 release Jan 17 14:40:48 could anyone recommend a yocto-compatible update framework that allows for both kernel and full sysroot updates and is easy to port? Jan 17 14:43:17 eduardas_m: try swupdate Jan 17 14:45:37 eduardas_m: https://wiki.yoctoproject.org/wiki/System_Update Jan 17 14:45:40 open-nandra, I am already trying it... I can build swupdate-image for my board, but am having problems generating compund swu images Jan 17 14:46:55 open-nandra, I have a problem similar to this one: Jan 17 14:46:58 https://groups.google.com/forum/#!topic/swupdate/O2VdV7SBVr0 Jan 17 14:47:31 sw-description does not get fetched Jan 17 14:48:35 also, to even build swupdate-image I have to resort to mixing my bsp krogoth release with meta-swupdate jethro because of incompatible u-boot-fw-tools patches meta-swupdate krogoth applies Jan 17 14:49:12 mainly because my bsp u-boot is older than meta-swupdate expects Jan 17 14:50:06 open-nandra, if you are using swupdate successfully, what platform are you running it on? Jan 17 14:50:26 I am trying to do this on the DART6UL from Variscite Jan 17 14:50:36 eduardas_m: nxp Jan 17 14:50:57 eduardas_m: it's gneric can be ported to amost of the platforms Jan 17 14:51:40 open-nandra, do you have any idea why the error I have described might happen? Jan 17 14:55:13 pohly: so i must have missed something in mut for rmwork, can you check quickly and see what i left out? Jan 17 14:55:55 zeddii_home, thank you for the link... I somehow overlooked that Jan 17 14:57:33 euarddas_m: which error? Jan 17 14:57:54 rburton, RP: should "event/ast: Add RecipeTaskPreProcess event before task finalisation" really be merged already? Jan 17 14:58:44 It's currently the first tentative implementation from RP, but wasn't quite ready yet (incomplete documentation, tasklist attribute not quite as it should be. Jan 17 14:58:50 pohly: I've not gotten to posting it yet Jan 17 14:59:31 RP: I included it in my revised rmwork patches because those depend on it and I wanted to test the concept. Jan 17 14:59:47 pohly: right, that is fine Jan 17 14:59:50 ... and then share the result. But it's probably not ready for merging. Jan 17 14:59:51 open-nandra, sw-description does not get fetched when generating swu compound image Jan 17 15:00:06 described in link I have provided Jan 17 15:01:05 rburton: your patches look complete to me, with that caveat about this one commit being tentative. What's not working? Jan 17 15:01:18 I am having the exactly same issue as described on the swupdate google group Jan 17 15:01:40 I've not tested this particular revision as thoroughly as the ones before, but it did seem to work okay to me. Jan 17 15:02:39 rburton: I assume you don't have my bitbake patch? Jan 17 15:03:46 RP: no, it's there - poky-contrib/ross/mut 84a935732a. Jan 17 15:09:30 anyone? :( http://pastebin.com/CJBhYjrz Jan 17 15:12:59 rburton: I see - one last minute cleanup broke the patch series. sed -i -e s/RunQueueSchedulerRmwork/RunQueueSchedulerCompletion/ bitbake/lib/bb/runqueue.py fixes it. Jan 17 15:23:30 I'm wrestling with the meta-qt5 layer, trying to get populate_sdk_ext to work. populate_sdk works just fine but populate_sdk_ext errors with an issue touching a nonexistant qt.conf file in populate_sdk_qt5_base.bbclass Jan 17 15:25:21 Does populate_sdk_ext work differently than populate_sdk? Really new to yocto so I'm not 100% sure where to start debugging this Jan 17 15:27:21 themikenicholson: very differently Jan 17 15:28:18 is there a good place in the docs to start reading so I'm not burdening everying here with my troubles :) Jan 17 15:43:31 RP: bitbake core-image-minimal succeeded with dnf \0/ Jan 17 15:43:37 rburton: ^^^ Jan 17 15:43:44 whether that image even boots is a story for tomorrow Jan 17 15:43:55 kanavin: yay :) Jan 17 15:46:47 RP: actually it does boot to login and then command prompt :) Jan 17 15:47:03 kanavin: an added bonus :) Jan 17 15:47:43 kanavin++ Jan 17 15:49:36 RP: would it make sense to call native tools from ./tmp/sysroots-components/$HOST_ARCH/-native/ ? In this case we'll not need to have an artificial recipe to build all required native tools. Jan 17 15:50:30 if anyone is feeling adventurous, https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/dnf-rpm4 Jan 17 15:50:42 (this branch will be force pushed to without mercy) Jan 17 15:50:56 kanavin: niiiice Jan 17 15:53:51 * kanavin goes for a tea+cake Jan 17 16:06:48 what's dnf? Jan 17 16:07:01 the new yum Jan 17 16:07:02 that said, kanavin, any luck on reproducers or non-reproducers for the chroot thing? Jan 17 16:10:32 morning! Jan 17 16:11:42 seebs: no luck :( rpm4 makes it hard to figure out which line of code exactly is causing the behaviour to switch from correct to incorrect Jan 17 16:12:03 rburton: I wonder why this error: Jan 17 16:12:03 selftest - ERROR - You don't seem to have the meta-selftest layer in BBLAYERS Jan 17 16:12:03 is not this warning: Jan 17 16:12:03 selftest - WARN - You don't seem to have the meta-selftest layer in BBLAYERS, adding it for you, thank me later. Jan 17 16:12:57 seebs: I'll try to 'bisect' the code a bit more to identify the offending line, but not today Jan 17 16:13:30 benjamirc: because that would be harder than just aborting :) Jan 17 16:13:54 benjamirc: absolutely easy to fix, as we know where meta/ is so we know where meta-selftest is Jan 17 16:14:22 rburton: just wanted to see if there was a compelling reason to do it the current way Jan 17 16:15:17 not afaik Jan 17 16:15:19 rburton: I haven't sent a patch in ages Jan 17 16:15:26 good practise then :) Jan 17 16:15:34 will do Jan 17 16:25:32 Hello everyone. reibax here, from Spain Jan 17 16:26:13 I need a lilttle bit of help... I don't know what else to do to find out what I am doing wrong Jan 17 16:26:50 yocto 2.1 krogoth. I have a custom distro that works fine when generating images for a imx6 board Jan 17 16:27:48 but if a create a new layer for generating the same image for qemu-x86, the distro configuration file is not read, and everything in the image ends up being different: no systemd instead of sysvinit, no ipk instead of rpm.... Jan 17 16:27:48 ed2: We can't make that work as their dependencies are missing :( Jan 17 16:28:52 RP: ok, can we call them from the native sysroot of image recipe then? Jan 17 16:29:23 ed2: yes, that would work Jan 17 16:29:47 when I do "bitbake -e amos-production | less" in the imx6, I can see how conf/bitbake.conf includes: /app/ClassA16/sources/meta-ca16distro/conf/distro/classa16.conf Jan 17 16:30:16 but if I do it when in the qemux86 environment, the configuration file of my distro is nowhere to be found Jan 17 16:30:23 what can I do to debug this? Jan 17 16:30:24 RP: is it possible to implement building native tool for specific recipe, e.g. bitbake parted —recipe core-image-minimal ? Jan 17 16:31:26 reibax: soundsl ike you didn't set distro in the other. read conf/local.conf. Jan 17 16:31:55 I'll try that, thanks. I will report back once I have check what you propose Jan 17 16:36:44 kergoth: a million thanks! I think you got it right! I now see that it is parsing the configuration file. Compiling now :) :) :) Jan 17 16:37:15 joshuagl: which version of debian are you using for bug 10933? Jan 17 16:37:16 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10933 normal, Undecided, 2.3 M2, joshua.g.lock, ACCEPTED , None-validated host distro such as debian-testing results in oe-selftest failures Jan 17 16:37:34 so kind of you yocti Jan 17 16:39:43 benjamirc: testing Jan 17 16:41:13 I see joshuagl, now I understand your bug, selftest should not care about SANITY_TESTED_DISTROS Jan 17 17:03:07 ed2: not really :/ Jan 17 17:04:25 RP: never mind. I think I found more or less acceptable solution. Jan 17 17:05:11 RP: when we run wic from bitbake all native tools should be built and available in the sysroot of image recipe. Jan 17 17:05:58 when we run wic not from bitbake wic will look at the image recipe sysroot and at the tool recipe sysroot. Jan 17 17:11:20 ed2,RP: why tie command line wic so closely to bitbake? I thought I should be able to run cli wic to build images w/o a full bitbake world and just use my installed tools (like parted). Is this wrong? Jan 17 17:20:18 RP: this is because of tinfoil limitation. As we now have tinfoil2 we can run bitbake from wic even when wic is run by bitbake, right? Jan 17 17:20:49 ed2: not sure that tinfoil2 was designed to do that Jan 17 17:20:56 RP: bug 10035 is the one I was talking about Jan 17 17:20:58 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10035 enhancement, Medium+, 2.3 M2, leonardo.sandoval.gonzalez, IN PROGRESS IMPLEMENTATION , oe-selftest: Use SSTATES without corrupting them. Jan 17 17:21:03 ed2: bitbake from bitbake is a generally bad idea Jan 17 17:22:52 khem: any news on the musl/network/linux 4.9 thing? Jan 17 17:23:15 benjamirc1: added a dependency to the bug Jan 17 17:25:51 RP: I assume that we need to track also the removal of the bitbake core-image-minimal from the selftest buildset Jan 17 17:32:05 RP, lsandov, I´m filing the bug and making it dependent of the previous shown Jan 17 17:37:53 RP, lsandov, joshuagl, done. bug 10937 filed. Jan 17 17:37:55 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10937 enhancement, Undecided, ---, joshua.g.lock, NEW , remove from oe-selftest buildsets the step for building an image prior the test session Jan 17 17:47:35 benjamirc1: yes, that helps thanks Jan 17 17:57:12 RP: is the current rss branch the one on poky-contrib? Jan 17 17:57:24 i'm guessing so, from a tbdiff with oe-core it looks like the poky version is newer Jan 17 17:57:56 kergoth: yes, the poky-contrib is the current one, need to separate out the bitbake pieces and submit them Jan 17 17:58:05 okay, thanks Jan 17 17:58:20 kergoth: been concentrating on fixing the bugs and getting the test scores up Jan 17 17:58:31 no worries, i figured Jan 17 17:58:54 kergoth: oe-selftest down to six failures in the last run Jan 17 17:59:11 kergoth: musl is the last big thing that is bust that I know of Jan 17 17:59:24 and wic but ed2 is working on that Jan 17 19:51:15 Still fighting meta-qt5 trying to get populate_sdk_ext working, while populate_sdk works just fine Jan 17 19:51:51 I think I understand why its failing, I'm just hoping someone can confirm my understanding or tell me I'm way off base Jan 17 19:55:10 The error is a result of the populate_sdk_qt5_base.bbclass here https://github.com/meta-qt5/meta-qt5/blob/9aa870eecf6dc7a87678393bd55b97e21033ab48/classes/populate_sdk_qt5_base.bbclass#L7 Jan 17 19:55:32 the touch command fails because the directory ${SDK_OUTPUT}/${SDKPATHNATIVE}${OE_QMAKE_PATH_HOST_BINS} does not exist Jan 17 19:57:01 Is this working on the normal SDK and failing on the extensible SDK because the normal SDK installs all of the packages by default while nothing is installed on the extensible SDK Jan 17 19:58:04 which would mean the install step for the native qmake isn't occuring when generating the ext. sdk, meaning that the directory containing qt.conf is never getting created? Jan 17 22:30:41 Does anyone know how to configure poky to not use git:// for everything? Jan 17 22:30:51 My company blocks git protocol Jan 17 22:31:03 For the life of me I can't figure out how to make it clone using https:// Jan 17 22:39:35 ythl: does https://git.yoctoproject.org/git/poky work? Jan 17 22:42:18 yes Jan 17 22:42:33 However, when I run toaster Jan 17 22:42:47 it always tries to get git://git.yoctoproject.org/poky Jan 17 22:42:52 which does not work Jan 17 22:43:03 I've tried changing the remote with git remote set-url Jan 17 22:43:08 but it just ignores that Jan 17 22:43:19 toaster pulls its urls from the layer index. Jan 17 22:46:05 So for example, if I want to change the meta-poky layer url Jan 17 22:46:16 How would I do that? Jan 17 22:49:14 that depends on whether toaster uses the bitbake fetcher for layers. if it does, you can use PREMIRRORS or git replacements, if not, then afaik git would be your best, or possibly only, option Jan 17 22:49:20 * kergoth doesn't know much about toaster Jan 17 22:53:14 argh Jan 17 22:53:22 can we please stop hardcoding versions in the selftests Jan 17 22:53:33 upgrading mdadm shouldn't result in tests failing because the version changed Jan 17 22:53:49 indeed Jan 17 22:54:29 AssertionError: '.TH MDADM 8 "" v4.0' != '.TH MDADM 8 "" v3.4' Jan 17 23:59:38 halstead: ping Jan 17 23:59:50 Good afternoon moto-timo! Jan 18 00:00:16 halstead: so I pushed a new eclipse-poky-contrib/timo/neon.2-smoke-test including osu osl site Jan 18 00:00:33 Any success? Jan 18 00:00:35 halstead: I'm not sure what is going on, but maybe a re-sync? Jan 18 00:00:45 halstead: osu osl looks like what I expect Jan 18 00:01:03 I haven' Jan 18 00:01:22 t tried to run these myself. Jan 18 00:02:38 halstead: if I go to the full URL of the feature it is there... I don't understand what is missing in the p2 metadata Jan 18 00:04:17 moto-timo, Checking that specifically. Jan 18 00:06:26 moto-timo, It looks like there might be a line ending change that didn't sync. Jan 18 00:07:03 halstead: sigh if that's it Jan 18 00:08:47 moto-timo, It was in the parent dir and so not synced. Identical now. Jan 18 00:09:26 halstead: phew Jan 18 00:09:39 moto-timo, Working as expected? Jan 18 00:10:19 halstead: winner winner chicken dinner Jan 18 00:10:51 halstead: thanks for figuring it out Jan 18 00:11:47 moto-timo, okay. I'll re-sync the whole neon directory in the future. I'd just synced the new 201612211000 dir but not the parent. Jan 18 00:12:31 moto-timo, Didn't want to accidentally sync over something we depended on. But it seems like that's not really a concern. Jan 18 00:12:34 halstead: there must be some index stuff in the parent Jan 18 00:12:55 halstead: especially not now that Neon.1 is already merged to git repo Jan 18 00:14:23 moto-timo, And as far as the P2 repository. It sounds like we don't need a Nexus2 server for that and we can script creating it from our Nexus3 server. I don't have all the details at the moment. Jan 18 00:14:49 moto-timo, Does that sound right? Jan 18 00:15:22 halstead: since Neon.2 is now available on Maven Central, I expect to not need p2 repo and not need Nexus2 Jan 18 00:15:43 halstead: tl;dr correct Jan 18 00:16:01 * halstead checks off a box on his check list. Jan 18 02:13:47 hey , I ran into this problem too https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-December/002307.html ... ideas ? Jan 18 02:14:02 somehow I suspect meta-xilinx-tools implementation is crap Jan 18 02:21:57 Marex: so since this is morty I think the problem here is it's attempting to use python2 code in python3 Jan 18 02:22:57 what it's doing is a horrible hack, instead it should be using pythonnative and having pyyaml-native or similar in DEPENDS Jan 18 02:23:22 at least I think that ought to work Jan 18 02:23:45 bluelightning: I just printed sys.path and saw python3 there too, hehe Jan 18 02:27:14 bluelightning: but even if I do inherit pythonnative, I still get python3 stuff in sys.path Jan 18 02:27:29 bluelightning: does that have something to do with bitbake using python3 ? Jan 18 02:37:46 of course, it's trying to use python2 yaml with python3 ... but how does one fix it, imherit pythonnative doesn't seem to do the trick Jan 18 02:38:16 Marex: you need to be using python3 when you're in this context, I don't think there is a way around that Jan 18 02:38:40 so whatever you execute it needs to be python3 - that's independent of what you do on the target though, that can still be python2 Jan 18 02:38:43 bluelightning: sigh ... using vendormetalayers ... sigh ... Jan 18 02:38:55 bluelightning: thanks, I suspected as much Jan 18 02:42:08 bluelightning: jupp, packing up python3-pyyaml and using python3native and cleaning that horrid hack makes it work like charm, thanks again ! Jan 18 02:59:32 Marex: looks like Crofton|work was asking about this same issue on the oe mailing list just today **** ENDING LOGGING AT Wed Jan 18 03:00:00 2017