**** BEGIN LOGGING AT Mon Apr 20 02:59:58 2015 Apr 20 07:31:56 good morning Apr 20 08:12:36 morning all Apr 20 08:13:09 morning Apr 20 08:18:09 hi bluelightning, nrossi Apr 20 08:18:59 hi nrossi, mckoan Apr 20 08:53:07 Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (cortexm1t2-vfp). Apr 20 08:53:28 for DEFAULTTUNE := "cortexm1" Apr 20 10:36:49 JaMa: does building qemuarm for DEFAULTTUNE := "cortexm1" work four you on current master? Apr 20 10:41:29 JaMa: specifically, for me sanity complains about "does not contain TUNE_PKGARCH (cortexm1t2-vfp)" where indeed PACKAGE_ARCHS only contains ... "armv7a armv7a-vfp armv7at2-vfp cortexm1-vfp qemuarm" Apr 20 10:45:15 (it would be handy if sanity bbclass would actually tell which PACKAGE_ARCHS it has seen, like http://paste.debian.net/167748/ ) Apr 20 10:45:25 blindvt`: please check how t2 got enabled and my guess is that Apr 20 10:45:26 PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexm1-vfp" Apr 20 10:45:31 shouldn't have at Apr 20 10:45:32 PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexm1-vfp" Apr 20 10:45:41 +PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7a} cortexm1-vfp" Apr 20 10:47:32 JaMa: yea, the t2 handling is a bit .. erm .. non-obvious with all those suffix handling Apr 20 10:47:43 even the vfp shouldn't be enabled imho Apr 20 10:47:50 TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1" Apr 20 10:48:02 what's your list of TUNE_FEATURES? Apr 20 10:48:57 In my local.conf i just have DEFAULTTUNE := "cortexm1" and ARM_INSTRUCTION_SET := "thumb" Apr 20 10:50:48 JaMa: tune-cortexm1.inc hast just one TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1" here Apr 20 10:58:18 JaMa: I appended cortexm1t2-vfp to PACKAGE_EXTRA_ARCHS_tune-cortexm1 and sanity stopped to complain. the cortex-a do the same it seems. I didn't think through if this is sensible though. [I guess it is not at least doesn't feel like. Not sure of cortexm1 are even thumb1-capable -- i thought they weren't] Apr 20 11:01:29 JaMa: i.e. http://paste.debian.net/167750/ Apr 20 11:02:33 JaMa: but according to http://en.wikipedia.org/wiki/ARM_Cortex-M the cortex-m1 are v6-m and not v7 so isn't the PACKAGE_ARCHS that contain all those armv7* just wrong? Apr 20 11:04:29 either way. it's now good enough for me to build me a non-arm image Apr 20 11:05:55 do you have bitbake -e output which shows how your TUNE_PKGARCH was set? Apr 20 11:06:15 that t2 and vfp are still very suspicious and the root cause of all this mess IMHO Apr 20 11:07:53 JaMa: no, not readily. You should see it if you set your local.conf as per above 2 vars and "require conf/machine/include/tune-cortexm1.inc" in meta/conf/machine/qemuarm.conf i guess Apr 20 11:08:19 instead of the existing require tune-*inc in qemuarm Apr 20 11:10:28 JaMa: so yea, under the assumption that cortexm1 is v6 and not v7, the feature-arm-thumb.inc would not do the t2 mess, it seems. Apr 20 11:38:40 JaMa: qemu-system-arm for versatilepb -cpu cortex-m3 segfaults with a NULL GIXState in gic_set_pending_private. Is there a reason that qemu-git uses some ancient (?) SRCREV? Unfortunately qemu-2.3.0 is not out of the door just jet, it seems Apr 20 11:38:53 s/GIX/GIC/ Apr 20 11:52:05 apparently I work with oe-classic Apr 20 12:04:22 Crofton|work: I didn't see your reply to Ed on the mailing list... Apr 20 12:04:34 I did reply .... Apr 20 12:04:42 then left twon for 3 days Apr 20 12:13:35 Crofton|work: your reply never made it to the ML, at least it's not in the archive Apr 20 12:13:41 fark Apr 20 12:13:44 let me check Apr 20 12:13:55 I didn't say anything because I thought you had... Apr 20 12:17:34 It went to Ed only, forgot reply-all Apr 20 12:21:13 Crofton|work: unfortunately it was missed on review as a result... oh well, at least the bug is fixed Apr 20 12:21:50 I'm still stumped at how someone could come up with oe-classic wrt to current work flow Apr 20 12:43:43 hey guys what is the easiest way to add a package in the build? for example libstdc++ Apr 20 12:43:47 or nano? Apr 20 12:46:23 Hopefully Ed doesn't think I am persecuting him :) Apr 20 12:46:40 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7631 Apr 20 12:46:52 Cyric: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Apr 20 12:49:34 adding a lib manually should set off a ton of alarm bells Apr 20 12:54:33 Cyric: adding libraries directly usually isn't needed, because we set up runtime dependencies on shared libs automatically Apr 20 12:55:27 well the problem is that i need qt5 qmake Apr 20 12:55:38 and is not in the repo Apr 20 12:56:25 so i would like to create a sysroot with OE and then use it for manually cross compiling and installing qt5 on the immage Apr 20 12:57:15 but i believe that the sysroot must have all the dependency required by QT5-qmake Apr 20 12:57:18 you need the meta-qt layer? Apr 20 12:57:36 the meta qt-layer does not include qmake Apr 20 12:57:48 at least not the version 5 Apr 20 12:58:06 only the qt4.8 but this is not good enought for me Apr 20 12:59:11 in general qmake is included in QTBase... but it seems that in this case has been removed Apr 20 13:00:01 i tried to bitbake meta-qt5-toolchain but it fails Apr 20 13:22:26 seems like we need a bbclass for people that use wic to manage building the required tools Apr 20 13:25:48 at OEDAM JaMa suggested we have a class for calling wic from within the build system, that sounds like a good idea to me Apr 20 13:26:02 we should probably enter a bug for that at minimum Apr 20 13:26:44 there are two pieces to the puzzle Apr 20 13:27:12 I just use a script with wic, but I would like a way to record the required utilities Apr 20 13:42:51 why history commands are not persistent? Apr 20 13:43:15 ? Apr 20 13:43:19 s/not/no longer Apr 20 13:43:39 since I'm using YP dizzy I have new weird behaviour Apr 20 13:44:12 I wonder if is a new feature or a bug Apr 20 14:04:08 mckoan: bash? busybox? something else? Apr 20 14:07:58 bluelightning: YP default, /bin/sh -> /bin/bash Apr 20 14:09:43 actually the default is busybox ;) Apr 20 14:09:46 but anyway Apr 20 14:18:01 bluelightning: doh! Apr 20 14:20:57 mckoan: is it possible a dependency got added that has pulled in bash whereas previously you had busybox? Apr 20 14:23:40 bluelightning: may be, actually I realized that only today Apr 20 14:24:06 bluelightning: lokks like a fsl standard behaviour Apr 20 14:27:56 where's the typical place in a oe build to inject a version number into a rootfs? i'd like the repo manifest file that was used to build the image into its rootfs. Is rootfs postprocessing the way to go? Apr 20 14:28:25 mago_ yes Apr 20 14:29:01 I made a snippet and require it in each image Apr 20 14:29:10 for our private layers Apr 20 14:29:23 but we do not need the whole manifest Apr 20 14:29:43 woglinde: same here Apr 20 14:29:54 cool, that was my next question.. how to make this injection into all standard images of our distro. i was thinking i'd create a new "core-image"-like class and let all my images inherit that Apr 20 14:30:17 woglinde: what do you ship with a build if not the whole manifest? Apr 20 14:30:40 mago machine Apr 20 14:30:45 and such on Apr 20 14:32:04 mago a uuid create by uuid distro distro version date Apr 20 14:32:22 and the image name of course Apr 20 14:33:46 woglinde: hm, okay. but won't that change for each rebuild? Apr 20 14:34:01 i would like something that i can use to reproduce that exact build at a later time Apr 20 14:45:18 mago sure thats the reason Apr 20 14:45:25 to have a manifest Apr 20 14:45:47 so we can verify a machine has the image it should have Apr 20 14:45:55 and not some developer stuff Apr 20 14:46:20 but when you use opkg update upgrade Apr 20 14:46:38 the information might be outdated ;) Apr 20 14:54:40 can anyone see anything obviously broken in the following user password config: Apr 20 14:54:43 EXTRA_USERS_PARAMS_append = 'usermod -p "`cat ${WORKDIR}/secret-root.txt | mkpasswd -m sha-512 -s`" root;' Apr 20 14:55:07 The result is an image that wont authenticate Apr 20 14:55:30 doing a usermod command exactly like that on a device works perfectly Apr 20 14:57:43 pompomJuice: I believe our version of usermod provides a -P option to take the plaintext password, I'd suggest using that Apr 20 14:58:05 pompomJuice: also, if you're using _append, always put a leading space in the value Apr 20 14:58:22 aah ok Apr 20 14:58:25 I will try those Apr 20 14:58:32 pompomJuice we use openssl passwd -1 Apr 20 14:58:35 what you say, "our usermod" Apr 20 14:58:54 that produces a working passwd for /etc/passwd Apr 20 14:58:54 pompomJuice: OE patches that option in Apr 20 15:00:09 let me try that -P Apr 20 15:00:37 my colleague set us up that command but he never tested it Apr 20 15:04:13 I'm assuming btw that you've considered the security implications of having every device have the same root password on it... Apr 20 15:04:53 I guess we thought it might be a maintenance nightmare if all are on some random password? Apr 20 15:05:07 but no Apr 20 15:05:14 we are kinda noobish when it comes to security Apr 20 15:06:11 nobody is supposed to have this password but me Apr 20 15:06:43 okay I am heading home Apr 20 15:06:47 till later maybe Apr 20 15:06:59 EXTRA_USERS_PARAMS_append = ' usermod -P "`cat ${WORKDIR}/secret-root.txt`" root;' Apr 20 15:07:12 would that backtick cat command work inside your usermod mechanism? Apr 20 15:07:20 I dont want the password in our VCS Apr 20 15:08:27 pompomJuice hehe good idea Apr 20 15:09:22 the secret-root.txt is fetched and destroyed on each build. It originates from a location that only I can access. Apr 20 15:09:42 surely someone could look at the file during do_rootfs... but still Apr 20 15:11:59 only I know what is cooking on our buildserver Apr 20 15:14:05 it'll be in the log/run files for the task Apr 20 15:14:20 only the hashed value should end up on the target though Apr 20 15:14:54 the issue is if someone reverses or otherwise obtains that password, they then have root access to every other device with the same image on it Apr 20 15:30:34 http://stackoverflow.com/questions/tagged/openembedded Apr 20 15:30:59 thansk to everyone keeping an eye on this Apr 20 15:59:09 http://pastebin.com/4Ck2Txuu Apr 20 15:59:13 libarchive fails Apr 20 16:42:21 cleansstate libarchive and restarting clears the hurdle Apr 20 16:42:25 RP, ^^^ Apr 20 16:43:13 Crofton|work: I think there is a patch on the list for that Apr 20 16:43:23 ok Apr 20 16:43:23 just checking Apr 20 16:43:24 Crofton|work: I'm not 100% convinced its right though Apr 20 16:44:23 seems weird, glad someone else is thinking about it Apr 20 18:37:36 RP: short question, from your perspective, is it generally OK to use an bb.event.RecipePreFinalise handler to preprocess some variables? I'm referring to my multi-kernels suggestion, wondering if the direction I took makes sense at all? Apr 20 18:39:45 do note that use of RecipePreFInalise is only appropriate if you're okay operating against unfinalized variables (e.g. you don't care that values you get will not have appends/prepends/overrides/etc applied), unless you want to manually finalize and then use that input to alter the unfinalized datastore. cant' speak to this particular case, lacking context. i'm sure rp will comment, but figured i'd speak up in case he's elsewhere Apr 20 18:41:27 kergoth: well yes its a case where I need to do some preprocessing/manual finalization (couldn't find another way) Apr 20 18:41:33 * kergoth nods Apr 20 18:42:19 but before I do another spin of the patch it'd be cool to have a hint from the grandmaster if this makes sense at all, because some concerns were raised if this would have impact on performance etc. Apr 20 18:43:54 fair enough Apr 20 19:34:09 anybody ever experienced internal compiler errors with m4-native, OE dizzy, and gcc 4.8.2 (ubuntu 14.04) ? Apr 20 19:38:37 huh. works fine now after a reboot. that's weird. Apr 20 21:50:32 _dv_: ICE with a -native recipe means it's your host's compiler failing Apr 20 21:50:56 * kergoth gets a qemu-native ICE on ubuntu all the time, thankfully its transient, the second bitbake always succeeds Apr 20 21:50:56 which can mean one of two things: host compiler bug, or hardware issues Apr 20 21:54:20 that's worrisome, i just hit an ICE in nativesdk-qemu.. you'd think it'd be a problem with this VM or th emachine it's on, but it's only ever qemu doing this here Apr 20 22:14:13 Jin|away: FWIW RecipePreFInalise is really as a last resort and if you can do it a different way, I'd prefer to. Equally there are some things which really can only be done with it. Apr 20 22:15:07 Jin|away: With the multiple kernels thing, I think we should probably add support for this directly into the kernel classes. We should also take the opportunity to clean up some of the classes, particularly around linux-yocto Apr 20 22:15:24 Jin|away: that is my take anyway :) Apr 20 22:17:23 kergoth: its worth to have gcc-native Apr 20 22:23:31 khem`: I have a recipe for nativesdk-gcc btw. Its horrendous though due to relocatability issues with gcc :( Apr 20 22:24:01 khem`: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=0ec9a92d3e2e4f1d6fd2b38a2395d19e301b634c - see rp.patch in there Apr 20 22:24:26 hmm EXEC_PREFIX should be enough Apr 20 22:24:51 GCC_EXEC_PREFIX points to a dir if we preserve it then it will relocate itself Apr 20 22:25:16 khem`: its not that simple since we relocate libdir and base_libdir Apr 20 22:25:39 sysroot ? Apr 20 22:25:47 khem`: doesn't help Apr 20 22:25:52 hmm Apr 20 22:26:09 oh nativesdk Apr 20 22:26:18 not native right ? Apr 20 22:26:22 khem`: right Apr 20 22:26:35 thats a different beast yes I agree Apr 20 22:26:59 * khem` has 46 more recipes to get world building with musl Apr 20 22:27:02 khem`: I ended up extending the spec syntax :/ Apr 20 22:27:11 wow Apr 20 22:27:13 thats gross Apr 20 22:27:25 I should look at the patch Apr 20 22:27:32 khem`: yes ;-) Apr 20 22:27:46 khem`: I hope that isn't 46 more patches to OE-Core for musl btw. I'm getting worried about the shear number of patches we're carrying for it Apr 20 22:28:10 We're trying to reduce the number of patches, not collect them :/ Apr 20 22:28:12 RP: they are getting upstreamed very fast Apr 20 22:28:22 so I promise by 1.10 they will be gone Apr 20 22:28:38 Yes I am in that camp too Apr 20 22:29:04 thats why I am tryin to create git trees and gitify our patches for components Apr 20 22:29:08 so its easier Apr 20 22:29:13 hopefully Apr 20 22:29:41 good thing is musl's patches 80% are real fixes Apr 20 22:29:51 which is making package better Apr 20 22:29:57 its not one of hack just for musl Apr 20 22:30:08 some of them are Apr 20 22:30:17 but thats small number Apr 20 22:30:22 yes, that helps Apr 20 22:30:40 thats the reason upstream package maintainers are accepting them Apr 20 22:30:47 the xorg hack is atrocious mind ;-) Apr 20 22:30:48 except kernel :) Apr 20 22:31:08 there is a reason why lazy binding is wrong Apr 20 22:31:13 I like what we do with musl Apr 20 22:31:23 time to pick kidlets Apr 20 22:45:09 how do I prevent patchfiles from being used and .tar.gz files from being unpacked when they're part of the SRC_URI ? Apr 20 22:45:58 boolean url parameters. unpack= and apply= Apr 20 22:46:10 e.g. http://foo.bar/baz.tar.gz;unpack=no Apr 20 22:46:16 iirc anyway Apr 20 22:46:56 1/0 yes/no true/false are all valid Apr 20 22:47:14 i think yes/no is the convention, however Apr 20 22:47:15 thanks kergoth Apr 20 22:47:24 since it reads like english Apr 20 22:47:25 np **** ENDING LOGGING AT Tue Apr 21 02:59:58 2015