**** BEGIN LOGGING AT Thu Dec 15 03:00:01 2016 Dec 15 07:18:18 does yocto supports octeon ii? Dec 15 07:18:32 or rather, ubnt's 8-port edgerouter pro? Dec 15 07:23:25 mjkr: yocto itself certainly not, as it is per defintion an umbrella project. i guess you mean, if there is an OE compatible BASp layer Dec 15 07:23:45 I'm looking for BSP rather Dec 15 07:23:52 there is one already for erlite Dec 15 07:24:05 but not e220 aka epro-8 Dec 15 07:25:25 mjkr: poky comes with a MACHINE config for edgerouter http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine/edgerouter.conf Dec 15 07:25:52 mjkr: so if there is nothing finished yet, this could probably serve as a starting point Dec 15 07:27:52 hmm does erlite build use this file? Dec 15 07:28:58 mjkr: no idea. Dec 15 08:37:07 good morning Dec 15 09:45:54 has anyone seen oe-selftest master AB to fail on wic.Wic.test_qemu? Dec 15 09:47:48 yeah ed blamed a wic selftest patch that i just removed Dec 15 10:03:18 ack Dec 15 10:50:33 Dear All, Dec 15 10:51:16 Is there any ipk repository (opkg packaging system), which I could use to install packages on my Internet connected target board? Dec 15 10:51:49 I do have my rootfs from Yocto autobuilder Dec 15 10:51:57 and I would like to add some extra code there Dec 15 11:05:06 lukma1: the idea is that you build your own Dec 15 11:06:57 lukma1: angstrom is a yocto distro that provides package feeds, if you don't want to build yourself Dec 15 11:10:55 guys, what is the difference between require and include directives? Dec 15 11:14:27 also I have a problem: I have added IMAGE_POSTPROCESS_COMMAND += "test" and write test function. After exececuting bitbake image I don't see that this function had executed :-( Dec 15 11:15:26 Ox4: include doesn't throw an error if the file doesn't exist Dec 15 11:15:28 require does Dec 15 11:28:39 rburton: understood, thank you Dec 15 12:30:29 rburton: you mean this patch? https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/lib/oeqa/selftest/wic.py?id=1b32c6ed025745cb06b7c28ca0fe9e416ce7abfa Dec 15 12:34:13 mborzecki: that should have fixed it. it appeared on the autobuilder again, likely a patch i removed. Dec 15 12:36:54 yeah, i've reverted it locally and still running in problems with wic.Wic.test_qemu Dec 15 12:40:53 that should have been the fix, not the cause Dec 15 12:53:18 rburton: there's `WKS_FILE = "directdisk.wks"` in qemux86.conf, looks like only qemux86-64 was fixed Dec 15 12:55:05 ah Dec 15 13:05:22 rburton: will you fix it in master or should i send a patch? Dec 15 13:05:38 mborzecki: patch please Dec 15 13:05:54 ok Dec 15 13:31:56 rburton: posted to oe-core ml Dec 15 13:34:32 ta Dec 15 13:34:42 i hope the ab doesn't fail with that again Dec 15 13:34:49 trying to get M1 out and selftest takes SO LONG Dec 15 13:51:06 Hi, I am working with the arago project and encountered an error inthe category 'nothing RDEPENDS 'shadowpackagegroup-xyz'' The packagegroup is there but the 'shadow' is prepended for some reason I don't understand Dec 15 13:51:24 *nothing RPROVIDES Dec 15 14:03:39 m4ho: sounds like you used _append but forgot to add the separator Dec 15 14:08:37 kergoth: would you say this is more in a realm of a providing or a depending package? Dec 15 14:09:15 the error clearly indicates the RDEPENDS of something is missing a space between shadow and packagegrouop-xyz Dec 15 14:09:22 so find what's adding packagegroup-xyz and add the missing space Dec 15 14:10:01 my bad, that was a typo, in the error it's "nothing RPROVIDES..." Dec 15 14:10:19 but you are right, I will have a look, thank you Dec 15 14:12:52 the error indicates nothing rprovides that because something rdepends on it, and there's no recipe that emits a package of that name or which rprovides that name Dec 15 14:12:59 so the root cause is still a runtime dependency Dec 15 14:13:17 unless you want to create a 'shadowpackagegroup-xyz' package, which seems unlikely :) Dec 15 14:13:48 heh, true Dec 15 14:13:56 alright, I think I got that Dec 15 14:40:54 who is the administrator of the Yocto wiki? I asked for user account there a few days back but haven't heard back. Dec 15 14:57:16 halstead: ^^ ? Dec 15 15:01:42 ipuustin: Usually Jefro approves new accounts but I can too. I'll do that for you now. Dec 15 15:03:58 ipuustin: All set. Thanks joshuagl for the ping. Dec 15 15:04:25 halstead, joshuagl: thanks! Dec 15 15:10:58 halstead: thanks, didn't know who was the right person. Dec 15 15:43:50 Hmm, wic just errored and showed nothing useful about why, had to enable debugging to see the real error? Dec 15 15:43:53 * kergoth scratches head Dec 15 15:45:00 Anyone know if it is possible to retrieve the PV of one recipe from another recipe (e.g., via some Python code or similar)? Dec 15 15:45:17 nope Dec 15 15:45:19 Saur: no Dec 15 15:45:29 recipe metadata is isolated by design Dec 15 15:46:06 Yeah, I was afraid that was the case. :) Dec 15 15:50:24 Is there some way for a recipe to only inherit a class when it is build for target (and not for native) when BBCLASSEXTEND = "native" is used? Dec 15 15:51:44 something like inherit ${@bb.whatever.inherits("target")} Dec 15 15:51:51 cant recall the function name for inherits Dec 15 15:52:06 bb.data.inherits_class Dec 15 15:52:33 that *might* work Dec 15 15:52:34 rburton: Isn't that for checking if a recipe has inherited a class? Dec 15 15:52:45 erm yeah, for native it works Dec 15 15:52:48 there's another function Dec 15 15:52:52 sorry, in a meeting too :) Dec 15 15:53:25 Can I use INHERIT_append_class-target in a recipe? Dec 15 15:53:35 no, INHERIT is global Dec 15 15:53:44 Meh Dec 15 15:53:49 FOO = "" Dec 15 15:53:53 FOO_class-native = "bar" Dec 15 15:53:55 inherit ${FOO{} Dec 15 15:53:59 ${FOO}, rather Dec 15 15:54:02 done Dec 15 15:54:02 yeah that Dec 15 15:54:10 Ah, that should work. :) Dec 15 15:54:29 easier to use overrides directly rather than doing an inline python conditional, though either would have worked Dec 15 16:06:25 Hmm, wic isn't obeying ROOTFS_SIZE, even though —size= isn't specified for my rootfs Dec 15 16:06:35 so the defined extra space in the metadata isn't being used Dec 15 16:07:38 * kergoth scratches head Dec 15 16:09:42 guys, can I use EXTRA_OECONF_remove and EXTRA_OECONF_append to replace a paremeter? Dec 15 16:11:14 yes Dec 15 16:11:16 of course, though remember that _remove cannot be undone, so a later bbappend in a future layer wouldln't be able to counteract that action Dec 15 16:11:32 also the remove/append would happen even if what you wanted to remove wasn't present, so keep that in mind Dec 15 16:11:36 Ox4`: the better fix is to submit a patch to parameterise the parameter, ie packageconfig Dec 15 16:11:42 not exactly a search/replace when the appedn is unconditional Dec 15 16:11:45 indeed Dec 15 16:17:20 what's ed bartosh's irc nick, again? Dec 15 16:17:28 alternatively, any other wic experts around? Dec 15 16:23:40 afaict this logic to obey ROOTFS_SIZE is never hit unless you explicitly pass in —rootfs-dir=. it only runs if part.rootfs_dir is set, but the fallback from —rootfs-dir= to IMAGE_ROOTFS doesn't happen when the partition is constructed, it's not done until the source preparation happens Dec 15 16:23:53 so extra space isn't added to the rootfs unless you explicitly specify it in the .wks Dec 15 16:25:36 if I want to append/override the .conf file from a bsp layer, which is the best way to do it? Is it right to do it in my distro .conf? Like this: MACHINE_FEATURES_mytarget = "bla bla" ? Dec 15 16:26:15 that's not really appropriate, it violates the expected orthogonality of distro/machine/image Dec 15 16:26:23 that is, every distro should work with any machine which shoudl work with any image Dec 15 16:26:36 but sometimes there's no other option, so it depends Dec 15 16:26:43 what are you looking to change? Dec 15 16:27:33 what other options there are? I would like to set MACHINE_FEATURES and IMAGE_FSTYPES Dec 15 16:27:41 why? Dec 15 16:27:44 for what purpose? Dec 15 16:27:46 which features? Dec 15 16:28:08 because the default features that are set I dont want them Dec 15 16:28:31 that explanation is useles Dec 15 16:28:35 :S Dec 15 16:28:46 it soudns like you should just create a new machine that includes the config of the other and adjusts MACHINEOVERRIDES to include both Dec 15 16:29:00 so it's your machine based on the other Dec 15 16:31:28 so there isn't something like .bbappend for configuration files Dec 15 16:34:24 no, absolutely not Dec 15 16:38:46 ok thank you kergoth Dec 15 16:39:29 for now I will continue to use local.conf Dec 15 16:40:23 * kergoth nods, that's reasonable. you *could* set them in your distro, just your distro would no longer be generally useful, it'd be specific to that machine, which goes against our policy. if it works for you, so be it, but the opposite of a best practice Dec 15 18:23:34 I have a patch that works perfectly fine if I drop into devshell and push it manual, but then fails otherwise. Dec 15 18:23:49 What might be the issue? Dec 15 18:26:29 hrm, looks like it might be a crlf issue Dec 15 18:57:17 lolsborn: I had the same problem adding a recipe where the source was written in a Windows environment. Ended up using dos2unix on the source and pushing it upstream before generating my patch. Dec 15 19:51:45 ld: bin/pseudo: No symbol version section for versioned symbol `memcpy@GLIBC_2.2.5' Dec 15 19:51:49 gahh, what the hell went wrong here Dec 15 19:52:13 hmm, wonder if meta-sourcery didn't properly rebuild something after switching toolchain versions.. it's supposed to.. **** ENDING LOGGING AT Fri Dec 16 02:59:59 2016