**** BEGIN LOGGING AT Tue Jan 27 02:59:58 2015 Jan 27 07:54:19 good morning Jan 27 09:28:26 morning all Jan 27 09:30:09 (indeed, UMT) Jan 27 09:33:58 Good morning. A new busybox was released today. Any plan on updating the one in yocto? Jan 27 09:36:03 lpapp: the maintainer of the busybox recipe is Chen Qi according to maintainers.inc, and I imagine he will get to it in due course; but you could ask him directly Jan 27 10:27:37 lo Jan 27 10:28:53 is there somewhere documented how DEPENDS_append_ works? resp. what will be extended to Jan 27 10:31:02 jaeckel: where would you be setting this? within a recipe, or outside it? Jan 27 10:43:12 is there a difference? Jan 27 10:43:48 and I would set it in a bbappend of a recipe Jan 27 10:44:59 jaeckel: ok, so what would you be trying to achieve exactly? the in this case would be some override such that the append was conditional upon that override being active Jan 27 12:16:14 I have an image that basically installs all packages from a packagegroup Jan 27 12:16:41 now I'd like to add qemu-native to these packages that get installed Jan 27 12:17:08 it works if I do a DEPENDS_append_ Jan 27 12:17:21 but it does not work if I add it to the packagegroup Jan 27 12:17:55 now I just searched for the documentation why this has to be included as DEPENDS Jan 27 12:19:05 hang on, you seem to be confusing two things - build-time dependencies and runtime Jan 27 12:19:24 DEPENDS specifies build-time dependencies, and qemu-native is QEMU for the build host and not the target Jan 27 12:19:53 yes, that's what I want Jan 27 12:19:56 adding to DEPENDS for a packagegroup wouldn't make sense, it should only have runtime dependencies on the packages that are in the group Jan 27 12:20:33 well my image has an IMAGE_INSTALL of the packagegroup Jan 27 12:20:51 s/has/does Jan 27 12:21:04 yes, IMAGE_INSTALL specifies packages, i.e. runtime targets Jan 27 12:21:34 is what you're attempting to do just to have qemu built and available on the host whenever you build the image? Jan 27 12:21:40 yes Jan 27 12:22:36 EXTRA_IMAGEDEPENDS += "qemu-native" should do that - EXTRA_IMAGEDEPENDS tells the system to build the specified build-time targets when building an image Jan 27 12:22:51 if you want to use our runqemu script you'll also need to add qemu-helper-native to that too Jan 27 12:23:15 note that all of our qemu* machines already do this via meta/conf/machine/include/qemu.inc FWIW Jan 27 14:09:57 what's the difference between inheriting cross.bbclass and not doing so? Jan 27 14:15:30 chankit1: cross vs. target namespace, cross is built for the host and not for the target, and cross has no packaging Jan 27 14:15:53 you can get an idea by having a look at what cross.bbclass itself sets Jan 27 14:21:04 bluelightning: I did examine cross.bbclass but what I think was cross.bbclass is supposed to override some of the settings set by autotools.bbclass isn't it? Jan 27 14:22:06 chankit1: not so much autotools.bbclass but more what bitbake.conf sets as defaults for the target Jan 27 14:36:07 NAMES Jan 27 14:36:15 NAMES Jan 27 14:36:17 names Jan 27 14:36:21 list Jan 27 14:36:44 JOIN Jan 27 14:56:46 snallase: if you're trying to do irc commands, you want /list and so on Jan 27 14:57:50 Hello Jan 27 14:58:31 I am new user to IRC. I want to post my question to all. Jan 27 14:59:46 Want to know if Yocto has browser project. Jan 27 15:00:15 Another question is: Can we build Chromium browser for Yocto? Jan 27 15:02:10 hm, not even possible to answer with https://github.com/OSSystems/meta-browser Jan 27 15:59:12 YPTM: armin is jamming to the music Jan 27 16:02:05 YPTM: I'm dialed in, but waiting on the horrible hold music.. Jan 27 16:02:05 YPTM: same for cristian Jan 27 16:02:30 YPTM: meaning, I am enjoying it Jan 27 16:02:49 they've changed it.. it was a different kind of horrible a few days ago Jan 27 16:02:52 YPTM: hehe I am enjoying it :) Jan 27 16:03:06 stephen is on his way to remove the hold music :) Jan 27 16:03:08 YPTM: Access Code: 2705751 Temporary Chairperson Passcode: 8937 Jan 27 16:03:43 rburton: ping :) Jan 27 16:03:46 there I saved you all Jan 27 16:03:53 phew Jan 27 16:03:54 YPTM: Stephen Joined Jan 27 16:04:03 YPTM: bruce is on Jan 27 16:04:11 yptm: Alex Vaduva Jan 27 16:04:17 YPTM: tom z on Jan 27 16:04:18 YPTM Michael here. Jan 27 16:04:36 YPTM: Saul is on Jan 27 16:04:49 halstead: got your query too late yesterday and didn't see it :) Jan 27 16:05:36 YPTM: cristian present Jan 27 16:05:47 YPTM: Sona is on Jan 27 16:05:53 * RP is present Jan 27 16:06:11 lol, I've been fray for 24 years.. ;) (apparently I've been absent from the YPTM call for a bit too long) Jan 27 16:06:30 YPTM: Paul Eggleton is on Jan 27 16:07:40 YPTM ross on **** BEGIN LOGGING AT Tue Jan 27 16:12:13 2015 Jan 27 16:14:23 halstead: sounds like its been a rough ride, thanks for working through it! Jan 27 16:16:36 which OSS project? Jan 27 16:18:17 bluelightning, I think I figured out my dependency prob from yest ; thanks for the info to go back to a normal DEPENDS line. Jan 27 16:18:45 paulg: ok, great Jan 27 16:19:37 I do get coreutils populating the sysroot, but there are no prio symlinks, so when I run the devshell, I still get the host's /bin/stat etc Jan 27 16:19:52 the sysroot /bin dir has stat.coreutils but no symlink Jan 27 16:20:10 you talking about native-coreutils? Jan 27 16:20:16 fray, yep. Jan 27 16:20:18 coreutils-native Jan 27 16:20:47 Can't say I'm surprised.. but is there a reason you need it over teh host version (some mismatch in options or something?) Jan 27 16:21:03 yep. Jan 27 16:21:21 I need the symlinks so we can run help2man on the sysroot binaries. Jan 27 16:21:27 the alternatives code I THOUGHT was disabled in the -native case.. if not that might be a simple bug fix Jan 27 16:21:40 or, I have to patch coreutils to try and run foo.coreutils Jan 27 16:22:01 well it seems borken to me, hence why I mention it. Jan 27 16:22:10 python __anonymous() { Jan 27 16:22:10 # Update Alternatives only works on target packages... Jan 27 16:22:10 if bb.data.inherits_class('native', d) or \ Jan 27 16:22:10 bb.data.inherits_class('cross', d) or bb.data.inherits_class('crosssdk', d) or \ Jan 27 16:22:10 bb.data.inherits_class('cross-canadian', d): Jan 27 16:22:11 return Jan 27 16:22:19 having stat.coreutils in the sysroot bin dir w/o a symlink seems useless. Jan 27 16:23:01 it will lead to random build errors when people _think_ they are using the sysroot bins (like I was) but end up leaking out to the host bins Jan 27 16:23:12 YPTM is over Jan 27 16:23:54 paulg: don't we currently explicitly avoid help2man? or is that what you're attempting to fix? Jan 27 16:24:26 I'm looking at the coreutils package, and it looks "poorly" written for the update-alternatives.. Jan 27 16:24:28 YPTM : Bug 7015 - python: Disables SSLv3 Jan 27 16:24:29 bluelightning, the latter ; I want real manpages hence am trying to use help2man again, at least on non cross compile cases for x86 Jan 27 16:24:30 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=7015 normal, Medium+, 1.8 M2, sona.sarmadi, IN PROGRESS IMPLEMENTATION , python: Disables SSLv3 Jan 27 16:24:47 it's manually renaming stuff, the recipe shouldn't do that, the update-alternatives class should Jan 27 16:25:25 it would be nice to use update-alternatives in the sysroot at some point, or at least use our update-alternatives metadata to avoid using the links entirely, so the names are corret Jan 27 16:25:30 ah Jan 27 16:25:38 paulg, in the meta/recipes-core/coreutils/coreutils_8.23.bb: Jan 27 16:25:41 do_install_append() { Jan 27 16:26:08 bluelightning: you remember I asked about some issues with valgrind in qemu-arm? Jan 27 16:26:17 remove the rename bit, specifically the $i.${BPN}, it should only be $i Jan 27 16:26:25 with the exception that: Jan 27 16:26:28 mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN} Jan 27 16:26:30 still need to be there.. Jan 27 16:26:35 if that works, you've found and fixed the bug Jan 27 16:26:52 i.e.: Jan 27 16:26:53 [ "${base_bindir}" != "${bindir}" ] && for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i.${BPN}; done Jan 27 16:26:55 jaeckel: I don't recall to be honest, no Jan 27 16:26:55 should be Jan 27 16:27:03 [ "${base_bindir}" != "${bindir}" ] && for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i ; done Jan 27 16:27:20 fray, thanks. I'll test that after lunch ; stepping out shortly Jan 27 16:27:21 (and same with the next sbindir) Jan 27 16:27:32 bluelightning: okay, nervermind... we're just tracking it further down and when we got a solution I'll ask again where I should report it... Jan 27 16:27:38 definitey seems like a real bug though. Jan 27 16:27:41 he problem is the recipe is doing the rename in all cases, it should be the update-alternatives that does the rename -- only when necessary Jan 27 16:28:07 there is no way around the 'lbracket.${BPN}' case, but if you are really concerned aobut using coreutils '[' in the native version, that can be fixed as well.. ;) Jan 27 16:28:51 because until now we have a working version of valgrind in qemu-arm executed through proot, but only if rvm (the ruby version manager) is installed and some scripts of it are sourced in the shell that wants to valgrind... Jan 27 16:29:02 (I thought I fixed all of these in the past, wonder if this one got missed, or if it "came back" Jan 27 16:30:10 ahh looks like I missed this one.. Jan 27 16:30:16 coreutils 6.9 got it fixed, but the 8.x didn't Jan 27 16:30:22 commit 4bed7f31535f16dbe1f8bbab58921f12f1696f6f Jan 27 16:30:23 Author: Mark Hatle Jan 27 16:30:23 Date: Tue May 15 18:34:39 2012 -0500 Jan 27 16:30:36 at least thats why I thought I had fixed it.. I did.. just not both versions Jan 27 16:30:43 so yes, it's a bug and should be easy to fix Jan 27 16:38:29 fray: can you help the guy asking about ALTERNATIVE_* on the yocto list? since you're an expert in that area ;) Jan 27 16:39:08 whats the topic (I missed it obviously) Jan 27 16:39:20 NM, found it.. Jan 27 16:53:27 I answered, not sure it's what he wanted, but I didn't exactly undertand what problem he was having Jan 27 16:53:33 so I tried to cover all of the bases Jan 27 16:54:53 sona: do you already have https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 on your list? looks like a pretty major one Jan 27 16:54:55 Bug CVE: could not be retrieved: InvalidBugId Jan 27 16:58:09 hi, I am trying to force a dependency o na specific version of a package and it doesn't work Jan 27 16:58:35 RDEPENDS_${PN} += "gpu-viv-bin-mx6q (= 3.0.35-4.0.0)" DEPENDS += "gpu-viv-bin-mx6q (= 3.0.35-4.0.0)" Jan 27 16:59:09 I added this to my recipe but another (newer) version of gpu-viv-bin-mx6q gets built and included in my generated rootfs Jan 27 16:59:11 sona: forgot to follow up on this earlier - there's a cve for python 2.7.3 for daisy on the list, but nothing for master. can the fix be backported to the current master as the python upgrade isn't trivial? Jan 27 16:59:29 PlkMndy: you can't do DEPENDS with versions, only RDEPENDS Jan 27 16:59:56 rburton: ok, RDEPENDS is fine - I put both because I wasn't sure Jan 27 17:00:30 PlkMndy: to build the old version if there is many use PREFERRED_VERSION_gpu-viv-bin-mx6q = "the version you want" in your local.conf Jan 27 17:00:58 YoctoAutoBuilder: boo Jan 27 17:01:32 ok, I can do that. It makes switching between different kernels a bit more complex however (the kernel is what depends on that gpu package and need an exact version match...) Jan 27 17:03:40 I would like to write a bbappend for linux-yocto_3.14 that picks up a defconfig based on which architecture MACHINE is set to in local.conf. Options are genericx86, genericx86_64 and arm. Right now the builder runs a make menuconfig and writes a .config file rather than using my defconfigs in place. This is the pastebin URL for the bbappend I'm dealing with: http://pastebin.com/kFmmmC0H Jan 27 17:05:21 *sigh* .. but why a defconfig. Jan 27 17:05:22 sona: actually it looks like CVE-2015-0235 isn't applicable to any version of (e)glibc in releases we currently support Jan 27 17:05:34 just write a .cfg that has the values you want and let it be applied Jan 27 17:05:41 * zeddii dislikes defconfigs with a passion. Jan 27 17:07:02 zeddii: I can certainly diff -urN the defconfig files I have against the standard .config produced and add them Jan 27 17:07:30 zeddii: But this doesn't solve my problem of understanding how the decision which one to use is being made Jan 27 17:08:21 in that bbappend you pasted, it would be based on the machine that was being built, but unless you have those defconfigs in machine specific directories, the same one will be picked up for each. Jan 27 17:10:04 zeddii: I tried that. I created i586/defconfig and x86-64/defconfig, etc but it still kept producing .config from running make menunconfig instead of using the preconfigured one Jan 27 17:10:41 the kernel's config phase always runs, and hence what you get in .config won't always be just what was in the defconfig Jan 27 17:12:19 bluelightning: yes, I am looking at CVE-2015-0235, quite new, further reading: http://www.openwall.com/lists/oss-security/2015/01/27/9, maybe we should open a bug for this? Jan 27 17:12:43 ulf`, is this with master ? I can always run a test to make sure nothing unexpected is happening Jan 27 17:12:55 sona: well, as I said the last time we had an (e)glibc version that didn't have the fix in it would have been dylan, so I suspect not Jan 27 17:13:13 sona: if I am reading the material correctly that is Jan 27 17:14:28 zeddii: it's one behind master. I tried master yesterday and see the same error reported here: https://bugs.tizen.org/jira/browse/BTY-99 Jan 27 17:14:43 zeddii: 3.14.19 Jan 27 17:16:12 zeddii: Note the do_compile log attached. I'm unable to build a 32bit kernel Jan 27 17:17:09 rburton: For master, we have [Bug 7059] Upgrade python 2.x to 2.7.9 :) Jan 27 17:17:11 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=7059 enhancement, Medium, 1.8 M2, alejandro.hernandez, NEW , Upgrade python 2.x to 2.7.9 Jan 27 17:20:02 ulf`, it'll take me a few hours, but I'll poke around and get back to you .. I'm just finishing up testing on some new kernels, and have to get that done first. Jan 27 17:20:51 zeddii: thanks Jan 27 17:21:13 zeddii: I'm not to using Yocto and this is a good learning experience Jan 27 17:21:17 s/not/new Jan 27 17:23:27 ulf`, no problem. is there anywhere I can get those defconfigs ? somewhere in a tizen layer ? elsewhere ? Then I can run that very same test here (modulo the fact that I'm bumping everything to 3.14.29) Jan 27 17:24:02 zeddii: Do you have access to the Tizen gerrit? Jan 27 17:24:29 zeddii: If not I can upload a tarball to dropbox Jan 27 17:25:27 ulf`. no access here . or I should say that I've never been on tizen's gerrit. so if it needs an account .. I won't have one :) Jan 27 17:28:21 zeddii :) Jan 27 17:28:30 zeddii: I'll get you a download URL Jan 27 17:39:13 sona: until that happens can we backport a fix? Jan 27 18:30:53 fray, when I run git blame on the coreutils bb, it contains some of your update-alternatives stuff... Jan 27 18:30:56 coreutils: use new update-alternatives Jan 27 18:30:56 Jan 27 18:30:56 (From OE-Core rev: 4bed7f31535f16dbe1f8bbab58921f12f1696f6f) Jan 27 18:31:16 in commit 3f810e24628764413a0672e668953667dc62794f Jan 27 18:31:18 yes.. Jan 27 18:31:23 see myc omemnt above.. Jan 27 18:31:30 I updated one version but not the other Jan 27 18:31:41 this is git blame on the 8.x file ; not the 6.x one. Jan 27 18:31:53 so it appears someone undid something... Jan 27 18:32:02 look at git blame, go back to the original commit.. Jan 27 18:32:10 see the patch.. 6.9 was updated, 8.x wasn't Jan 27 18:32:43 'er.. see commit that is Jan 27 18:33:24 nope. Jan 27 18:33:34 both updated ; in both repos, it seems. Jan 27 18:33:53 paul@yow-pgortmak-d2:~/poky/openembedded-core$ git show 4bed7f31535f16dbe1|diffstat -p0 Jan 27 18:33:53 b/meta/recipes-core/coreutils/coreutils_6.9.bb | 46 ++++++++-------------- Jan 27 18:33:53 b/meta/recipes-core/coreutils/coreutils_8.14.bb | 49 ++++++++++-------------- Jan 27 18:33:53 2 files changed, 38 insertions(+), 57 deletions(-) Jan 27 18:33:55 and,,,,, Jan 27 18:34:09 op3:~/poky/build$ git show 3f810e24628764413a0672e668953667dc62794f|diffstat -p0 Jan 27 18:34:09 b/meta/recipes-core/coreutils/coreutils_6.9.bb | 46 ++++++++-------------- Jan 27 18:34:09 b/meta/recipes-core/coreutils/coreutils_8.14.bb | 49 ++++++++++-------------- Jan 27 18:34:09 2 files changed, 38 insertions(+), 57 deletions(-) Jan 27 18:36:21 ulf`, ping. Jan 27 18:36:43 zeddii: pong Jan 27 18:37:07 good news. and bad news. when I unpacked that layer, and built with the bbappend, I get a 32 bit configured kernel. Jan 27 18:38:02 fray, afaict so far - it was updated and simply doesn't work. :) Jan 27 18:38:10 but I would suggest a change with the bbappend, because all that I can guess at, is that the wrong config wss picked up from the layer. Jan 27 18:39:25 zeddii: OK Jan 27 18:39:28 I did this to ensure the right defconfig was used: http://pastebin.com/xxWU3vnM Jan 27 18:40:04 zeddii: And with this change it still fails Jan 27 18:40:17 zeddii: Did yo usee the do_compile log attached to the bug I pointed to earlier? Jan 27 18:40:29 nope. Jan 27 18:40:48 zeddii: https://bugs.tizen.org/jira/secure/attachment/16229/log.do_compile.13718 Jan 27 18:41:41 generic x86 should be 32bit .. Jan 27 18:41:53 hence my confusion. what exactly is the goal ? Jan 27 18:45:43 zeddii: Offer developers the means to build the Tizen IVI release using Yocto Jan 27 18:47:07 zeddii: I could tar up the whole git project and make it available to you Jan 27 18:48:33 right. but I'm more specifically interested in this kernel issue. Jan 27 18:48:47 are you saying that it is being configured 32 bit and breaking the compile phase, or something else ? Jan 27 18:50:27 zeddii: /home/test/tizen-Distro-latest/tizen-distro.1/build32ivimodellodev/tmp-glibc/work/genericx86-oe-linux/linux-yocto/3.14.19+gitAUTOINC+fb6271a942_902f34d361-r0/linux/scripts/mod/empty.c:1:0: error: code model 'kernel' not supported in the 32 bit mode Jan 27 18:51:17 right. and I'm saying .. that BSP should be 32 bit. so I'd expect that to fail. Jan 27 18:52:30 zeddii: Sorry, I don't understand. genericx86 =32bit Jan 27 18:53:39 or are you saying that that same thing builds in a non-linux-yocto kernel ? in that case, it's an issue I can address. otherwise, all I can say is that the defconfig and configuration of that kernel is fireing properly and there's no issue. Jan 27 18:54:44 so I'm saying, if you wanted 64 bit, why isn't genericx86-64 being used as the machine. Jan 27 18:55:33 zeddii: Building genericx86_64 works. The goal is to change MACHINE to genericx86 in case folks want a 32bit distro Jan 27 18:56:59 in that case the issue is in the kernel itself. and if I broke that build with a merge, I can fix it. but if it breaks everywhere, then the fix should be upstream. Jan 27 18:57:26 * zeddii peeks at the code Jan 27 18:58:03 zeddii: sure :) Jan 27 19:00:04 I'm building the kernel here. if it blows up, I'll see if anything obvious jumps out as to a crime I committed. Jan 27 19:01:36 ulf`, you aren't by chance using a lame arse 32 bit build host, are you? Jan 27 19:02:17 http://www.linuxquestions.org/questions/suse-novell-60/code-model-%60kernel%27-not-supported-in-the-32-bit-mode-756730/ Jan 27 19:04:40 paulg: nope :) Jan 27 19:05:20 let me be more specific -- you aren't using a 32 bit install on a 64 bit machine, are you? Jan 27 19:05:38 paulg: I can build 64bit so the build host is fine Jan 27 19:07:58 ulf`, every instance of that error I can find is someone building a 64 bit kernel on 32 bit install. Jan 27 19:08:14 ulf`, your host or toolchain is somehow whacked. I can build that kernel just fine on my 64bit ubuntu builder. Jan 27 19:08:32 * paulg wants to see "tail -n1 /proc/kallsyms " Jan 27 19:09:28 yow-bashfiel-d4 [/home/bruc...cripts/mod]> uname -a Jan 27 19:09:28 Linux yow-bashfiel-d4 3.16.0-25-generic #33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Jan 27 19:09:28 yow-bashfiel-d4 [/home/bruc...cripts/mod]> file empty.o Jan 27 19:09:28 empty.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped Jan 27 19:10:09 does anyone even know if yocto pretends to support building on a 32 bit host? Jan 27 19:10:19 I can't imagine even trying that. Jan 27 19:10:34 sounds like a complete WOFT. Jan 27 19:10:38 paulg: 0000000000000000 T parport_ieee1284_ecp_write_data [parport] Jan 27 19:11:18 ulf`, is the host install something listed as supported by yocto? Jan 27 19:12:08 paulg: It's Ubuntu 14.04 in a Xen VM Jan 27 19:12:35 you've definitely got something strange going on there. I know that things can go strange when switching from multilib to non multilib ; perhaps you should do a cleanall and/or push your sstate off a cliff. Jan 27 19:13:09 oh wait. is the kallsyms for the host machine and not the VM? Jan 27 19:13:17 paulg: I wiped sstate and work directory Jan 27 19:13:21 'cause that would be cheating. Jan 27 19:13:27 paulg: It's the output from the VM Jan 27 19:13:30 ok... Jan 27 19:13:41 * ulf` doesn't have access to the host :) Jan 27 19:14:12 But yes Jan 27 19:14:16 well that empty.c endian thing check is a part of the default kernel sources from 2005, so the wreckage you are seeing is not yocto specific, but breakage in your VM stuff. Jan 27 19:14:18 I wouldn't be surprised if the toolchain is broken Jan 27 19:14:36 gcc 4.9.1 Jan 27 19:14:54 and there is this strange error saying CFLAG fstack protector is not supported Jan 27 19:15:27 wander into a mainline kernel source tree and type "make ARCH=i386 defconfig ; make ARCH=i386" and see what happens. Jan 27 19:15:41 you will undoubtedly get the same error/explosion. Jan 27 19:18:00 That's not a valid test. It would use the Debian 14.04 toolchain and not the Tizen toolchain it builds before attempting the kernel Jan 27 19:22:47 put the tizen toolchan 1st in your path Jan 27 19:32:36 * paulg looks for fray... Jan 27 19:34:39 here now Jan 27 19:34:51 what the question? Jan 27 19:35:11 fray, any thoughts on why the update alternative stuff all looks there and in place but isn't firing? Jan 27 19:35:33 ...for coreuitls-native in the sysroot? Jan 27 19:35:44 sorry I'm lacking context.. Jan 27 19:35:52 update alternative doesn't work in native, full stop Jan 27 19:36:21 in the coreutils package, remove the $i.${BPN} and replace w/ $i let the rest of the system handle the update alternatives if building target installable packages Jan 27 19:37:38 ok, I somehow missed the "doesn't work for native" part. Jan 27 19:37:47 * paulg scrolls up Jan 27 19:38:14 to use update-alternatives you have to create a package. native recipes don't create packages, thus it can't work Jan 27 19:38:55 ok, so the fix is to make the update alternatives stuff somehow be target specific. Jan 27 19:39:24 it is normally.. the recipe is broken.. Jan 27 19:40:03 the bug is that coreutils (or whatever) is renaming things.. it shouldn't.. the update-alternatives system renames things when it's active.. it can't be active in a native package (so it won't rename) Jan 27 19:40:39 look at commit 4bed7f31535f16dbe1f8bbab58921f12f1696f6f (oe-core commit) Jan 27 19:41:04 poky - 3f810e24628764413a0672e668953667dc62794f Jan 27 19:41:24 you'll see in the first part, the rename was removed: Jan 27 19:41:27 - for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i.${PN}; done Jan 27 19:41:28 + [ "${bindir}" != "${base_bindir}" ] && for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i; done Jan 27 19:41:42 but in the second hunk, to the "newer" coreutils, it was not removed.. thats the bug.. Jan 27 19:41:46 it should have been removed Jan 27 19:42:10 - for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i.${PN}; done Jan 27 19:42:10 + [ "${base_bindir}" != "${bindir}" ] && for i in ${base_bindir_progs}; do mv ${D}${bindir}/$i ${D}${base_bindir}/$i.${BPN}; done Jan 27 19:42:22 that is wrong, it shouldn't be adding the ${BPN}. Jan 27 19:43:00 aha; at 1st glance the two changes appear the same ; now I see the BPN Jan 27 19:43:30 in the distant past, before the update-alternatives.bbclass.. it was up to the recipe to rename the files then use the update-alternatives command.. Jan 27 19:43:35 * paulg goes off to implement and test. Jan 27 19:43:48 when the bbclass was added, the rename was moved into the class (but support for the recipe doing the rename was kept, just in case) Jan 27 19:44:38 ...seems there are two stray ${BPN} left in there to nuke. Jan 27 19:45:25 ...let me revise that ; three. :) Jan 27 19:45:25 correct.. Jan 27 19:45:35 3rd one is for [ Jan 27 19:45:45 the 'mv' for [ to lbracket is correct.. Jan 27 19:45:50 but otherwise the rest are wrong Jan 27 19:46:17 ([ is a special case, due to implementation details, trying to auto rename '[' does all kinds of wrong things...) Jan 27 19:49:07 sure, but I'm saying this line.... Jan 27 19:49:11 mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN} Jan 27 19:49:18 needs to be Jan 27 19:49:21 mv ${D}${bindir}/[ ${D}${bindir}/lbracket Jan 27 19:49:55 and then we let these existing lines take effect: Jan 27 19:49:56 ALTERNATIVE_LINK_NAME[lbracket] = "${bindir}/[" Jan 27 19:49:56 ALTERNATIVE_TARGET[lbracket] = "${bindir}/lbracket.${BPN}" Jan 27 19:50:24 no.. BPN in this case right right... Jan 27 19:50:40 * paulg doesn't follow. :( Jan 27 19:50:54 when you use an alternative target name, the system won't automatically rename it.. so you need ot do the rename yourself.. Jan 27 19:51:05 it's an artifact of [ not being allowed in the auto rename code Jan 27 19:51:13 ALTERNATIVE_TARGET[lbracket] = "${bindir}/lbracket.${BPN}" Jan 27 19:51:25 ALTERNATIVE_TARGET won't rename the targeted item Jan 27 19:51:29 (when set) Jan 27 19:51:37 so mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN} is correct Jan 27 19:52:00 (and we don't want 'lbracket' because another system provider of '[' might also be called lbracket..) Jan 27 19:52:08 it's an unusual corner case specific to '[' Jan 27 19:52:24 ok, I'll take your word for it and patch coreutils to run help2man on lbracket if need be... Jan 27 19:52:46 * paulg marvels at what a time sink it has been just to crap out sane man pages. Jan 27 19:52:52 if your host system's [ doesn't work.. you've got more serious problems Jan 27 19:53:15 no thanks to coreutils and its rube-goldberg machine of extracting man text from frigging binaries. Jan 27 19:53:45 I wonder what kind of tinfoil hat acid trip the gnu folks were on when they invented that. Jan 27 19:53:56 It might make more sense to provide man text as pre-built then.. cause trying to construct it based on the host version of the commands is wrong Jan 27 19:54:07 they could (and may) be compiled completely differently.. Jan 27 19:54:51 blame the coreutils wankers then ; one would almost think they went out of their way to make it openly x-compile hostile. :( Jan 27 19:55:03 there is no easy prebuilt option. Jan 27 19:55:28 :)) Jan 27 19:55:46 and fwiw, the old coreutils 6.9 one was already using native build bins for the help2man task. Jan 27 19:56:03 no I'm saying to change how it works.. Jan 27 19:56:25 generate them, and then provide the generated versions and remove all of the code thats generating it from the host system.. Jan 27 19:57:07 ... and if I "generate" them, I'll be generating them from the host binaries. Jan 27 19:57:11 they're man pages, not dynamically generated... Jan 27 19:57:33 build target.. boot target, copy coreutils source to target.. configure, compile generate man, copy results back to host.. Jan 27 19:57:45 write patch that disables man page generation.. and instead uses prebuilt copies.. Jan 27 19:57:53 not feasible. Jan 27 19:58:05 rinse lather repeat for all supported arch? Jan 27 19:58:06 it's feasible.. you just don't want to do it.. :) Jan 27 19:58:15 re-do each time coreutils is uprev'd Jan 27 19:58:19 not feasible. Jan 27 19:58:20 first time, sure.. after the first time.. you don't ned to.. Jan 27 19:58:46 as coreutils updates, it's pretty easy to figure out what has changed and what hasn't.. this isn't the first itme we've had to pre-generate stuff and then watch it on updates.. Jan 27 19:58:49 well if your concern is them being out of sync, then your strategy suffers the same issue if we only do it the 1st time. Jan 27 19:59:24 but if you are out of sync host vs target.. bang it's game over.. if the native doesn't match the target.. bang game over.. Jan 27 19:59:25 etc Jan 27 19:59:58 meh, I think the concern is moot. Jan 27 20:00:18 I'm more concerned with the need to build coreutils for the host to get man pages for the target, it's just wrong Jan 27 20:00:33 (now within the target recipe building the items twice, sure.. thats self contained) Jan 27 20:00:50 so, to entertain your plan, if say I did gen these manpages, where would they live? Jan 27 20:01:21 meta/recipes-core/coreutils/coreutils-8.23 Jan 27 20:02:24 as raw foo.1 files, ujncomressed, untarred? Jan 27 20:02:29 yup Jan 27 20:02:33 yuck. Jan 27 20:04:24 I'd rather a hands-free step vs some manual maintenance nightmare. I guess we'll have to agree to disagree. Jan 27 20:05:16 I'm pretty sure that "chmod" for mips uses the same args as it does for x86-64. Jan 27 20:05:43 exactly why this isn't that big of a deal Jan 27 20:06:05 generate it once for all, diff and it's pretty clear they're the same.. comment on that.. and just manage the differences.. Jan 27 20:06:27 folks like Red Hat have a master man-pages system and they avoid building a lot of man pages like this (or patch them in different ways) Jan 27 20:09:16 well, I might be ok with thefting someone else's pregen'd manpages. I'm not going to build all arch and diff crap. Jan 27 20:09:23 for Gentoo, i maintain a prebuilt tarball of the man pages you can unpack over Jan 27 20:09:23 top the existing source release and get sanity again. Jan 27 20:09:24 http://distfiles.gentoo.org/distfiles/coreutils-8.23-man.tar.xz Jan 27 20:09:34 -- from http://comments.gmane.org/gmane.comp.gnu.coreutils.general/5809 Jan 27 20:10:27 Hi. I am having trouble getting a script to run after rootFS creation. I originally had a "ROOTFS_POSTPROCESS_COMMAND" line in my local conf file, but after updating Poky that stopped working. I have created my own layer and added a recipe with a "ROOTFS_POSTPROCESS_COMMAND" line in it to invoke my script. I added my layer to my bblayers.conf file, but nothing I do seems to make the script run. Jan 27 20:11:02 I think I am missing something simple (I am no expert here). I would *really* appreciate a pointer. Jan 27 20:16:26 ISTR that might have needed to be in a class and not a conf? Jan 27 20:16:40 I run the following and can confirm it works.... Jan 27 20:17:05 -------- Jan 27 20:17:06 $ cat classes/builder-base.bbclass Jan 27 20:17:06 inherit hosts Jan 27 20:17:06 ROOTFS_POSTPROCESS_COMMAND += "builder_configure_host ; " Jan 27 20:17:06 builder_configure_host() { Jan 27 20:17:06 # bbnote "builder: configuring host" Jan 27 20:17:07 echo "${HOSTNAME}" > ${IMAGE_ROOTFS}/etc/hostname Jan 27 20:17:09 } Jan 27 20:17:11 -------------- Jan 27 20:18:11 Thank you. I will give that a try. Jan 27 20:29:20 paulg: I have added a class file similar to yours. Do I need to do something special to "enable" it? Jan 27 20:29:58 I rebuilt my target and the script did not run. Jan 27 20:31:09 bryan_, yes, somewhere in your bb for your image type you need to add Jan 27 20:31:12 inherit builder-base Jan 27 20:31:34 Excellent. Thanks Jan 27 20:32:07 I also have this, as a default setting for hostname: Jan 27 20:32:10 $ cat classes/hosts.bbclass Jan 27 20:32:10 # can be overridden Jan 27 20:32:10 HOSTNAME ?= "op3" Jan 27 20:32:56 and accordingly my image bb has Jan 27 20:32:58 inherit hosts Jan 27 20:33:53 I don't recall exactly, but I either based it on the docs or on stuff zeddii said. Jan 27 20:38:01 Thank you paulg - your a life saver. This worked like a charm. Jan 27 20:38:15 no problem. Jan 27 20:55:38 fray, if I do go with prepackages manpages and steal the gentoo ones (or some other ones) we'll need to actively disable the half baked ones with the "OOOOPS I couldn't find perl" that coreutils currently generates... Jan 27 20:59:22 if you look, there is already a patch that is supposed to disable them when perl isn't available.. just recycle the patch and always disable it Jan 27 21:01:55 fray, no that hackery is a total fail ; it just avoids running help2man, as help2man is the perl part. Jan 27 21:02:20 ok Jan 27 21:02:21 so it generates half baked manpages ; which is what sent me on this quest in the 1st place. :-/ Jan 27 21:03:10 fray, e.g. http://pastebin.com/p81Fa4yK Jan 27 21:03:29 "nice" Jan 27 21:03:49 yeah, exactly. when I 1st saw that, I did a WTF? I have perl... Jan 27 21:03:50 personally I remove any refernce to 'info', as that is less useful that that man page Jan 27 21:04:23 info. Another useless rube-goldberg POS brought to you by gnu folks in a tin hat. Jan 27 21:04:35 info is horrible.. I can't believe they still think it was a good idea Jan 27 21:05:48 +1 Jan 27 21:29:39 * vmeson mumbles that info is fine if you live in emacs like RMS Jan 27 21:29:43 :) Jan 27 21:38:35 halstead: I know things are moving around right now, where would I find 1.8M1 release directories? Jan 27 21:39:05 sgw_, To download via http? Jan 27 21:39:29 sgw_, At http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-1.8_M1/ Jan 27 21:40:26 halstead: tried to go through the autobuilder.yp.org (which is how I remember!) Jan 27 21:41:37 sgw_, That's coming back soon. Jan 27 21:47:30 halstead: did you see my mail about proxies on the AB? Jan 27 21:47:59 rburton, Yes. I re-ran some of those failed builds and they worked. Jan 27 21:48:19 halstead: huh, of ross/mut? Jan 27 21:48:34 rburton, We don't actually use proxies on that set though. So I wonder if freedesktops.org was having trouble. Jan 27 21:48:51 rburton, Oh. No I tried with master. Jan 27 21:49:16 rburton, Was there trouble with sites other than freedesktops.org? Jan 27 21:49:42 * rburton looks Jan 27 21:50:58 halstead: apparently not, so you may well be right. i'll work through the other failures and try again later, thanks. Jan 27 21:51:19 Hi rburton :) Jan 27 21:51:53 huh, hi ulf`! :) Jan 27 21:51:57 what brings you here? Jan 27 21:53:10 rburton: Tizen on Yocto :) Jan 27 21:53:14 rburton: or why it fails :) Jan 27 22:49:02 otavio: yay u-boot in fsl is breaking again: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc/builds/168/steps/BuildImages/logs/stdio (ross/mut) Jan 27 22:49:24 thoughts welcome :) Jan 27 22:49:25 * rburton -> bed Jan 27 23:16:42 what the hell? fatal error: openssl/evp.h: No such file or directory Jan 27 23:17:05 is u-boot adding some kind of secure boot feature with crypto magic? Jan 27 23:20:08 * paulg starts an mpc8315-rdb build and will check for wreckage when he gets home. Jan 27 23:25:31 rburton: easy; their openssl seems to be messing up Jan 28 00:56:52 fwiw, I wasn't able to reproduce the u-boot fail on mpc8315 Jan 28 00:58:05 -rwxr-xr-x 2 paul paul 384680 Jan 27 19:53 u-boot-mpc8315e-rdb-v2014.07+gitAUTOINC+524123a707-r0.bin Jan 28 00:58:31 not sure if the 8315 is what the autobuilder was trying to build. **** ENDING LOGGING AT Wed Jan 28 02:59:59 2015