**** BEGIN LOGGING AT Fri Apr 12 02:59:58 2013 Apr 12 03:03:12 Where can I find my target python binary? Apr 12 07:26:10 good morning Apr 12 08:59:48 morning all Apr 12 09:03:56 hi mckoan Apr 12 09:11:53 hi mattnie Apr 12 09:36:43 is yocto 1.4 releases on 4/26/2013 cause the stabilization milestone was not met? Apr 12 09:53:40 kergoth: where did sub-bb go? Apr 12 09:53:59 oh you renamed it? Apr 12 09:54:37 mattnie: AFAIK, it was always scheduled for that date Apr 12 13:45:41 hi, I need to untar something after do_unpack (or before patch): is there a standard rule I can use inside my recipe? Apr 12 13:57:48 david-e_: unpack=1 Apr 12 13:58:32 tbh, i thought it unpacked all tarballs by default Apr 12 14:09:43 rburton: cheers. it gets automatically unpacked, but not where I want. Thanx for the tip though Apr 12 14:10:53 I guess I have to play with $S . will read some docs before aking stupid questions though Apr 12 14:12:26 david-e_: setting S is usually the right way to handle that, although there is also a subdir= parameter that can be used within SRC_URI Apr 12 14:12:52 david-e_: subdir is generally only used when you have two archives extracting the same dir, or for archives with no directory structure at all Apr 12 14:13:49 there are no stupid questions :) Apr 12 14:14:08 bluelightning: thanxh, I found the "striplevel" option too. still need some time to get used to all this new stuff:) Apr 12 14:15:31 david-e_: if you haven't seen it, those parameters are all covered in the reference manual - http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-SRC_URI Apr 12 14:16:17 i should stop reading the fetcher code and read the docs instead Apr 12 14:17:11 bluelightning: found it, thank you Apr 12 14:27:46 bluelightning: you were touching postinst scripts too, have you seen missing 'x' permission? I have it with opkg -rw-r--r-- 1 root root 0 Apr 4 16:43 /etc/rcS.d/S98run-postinsts Apr 12 14:38:11 JaMa: I haven't, no... this is with ipk though I presume? Apr 12 14:44:22 bluelightning: yes it it and it seems to happen only with older opkg already installed on target (at least buildhistory now shows the file with +x) Apr 12 14:45:03 bluelightning: I was just surprised to see that chmod only in postinst, but it makes sense as the postinst is creating that file Apr 12 14:46:42 bluelightning: btw cannot you use tee in REDIRECT_CMD ? Apr 12 14:46:58 JaMa: that REDIRECT_CMD shouldn't even be there Apr 12 14:47:09 JaMa: I have entered a bug to reimplement the functionality Apr 12 14:47:22 too late for 1.4 though Apr 12 14:47:26 ok Apr 12 14:47:36 do you have bug number handy? Apr 12 14:47:40 one sec Apr 12 14:47:57 some log would be nice to find out why systemd images hangs on run-postinsts Apr 12 14:47:57 JaMa: 4262 Apr 12 14:48:01 thanks Apr 12 14:48:24 yeah, it's not that it's not useful, it just hasn't been done in the right way Apr 12 14:49:04 JaMa: can you file a bug for the +x issue? Apr 12 14:49:13 (please) Apr 12 14:50:07 yes if I find some way to reproduce it or confirm it was like that in older images Apr 12 14:50:26 because right now I have seen it only in 1 from 10 (old) images I was testing Apr 12 14:59:30 JaMa: i've never seen a systemd image hang on postinst :/ is there a bug? Apr 12 15:01:54 not from me, but some other guys were reporting the same on ML Apr 12 15:02:33 hm must have missed that Apr 12 15:04:39 rburton: https://lists.yoctoproject.org/pipermail/yocto/2013-April/015300.html Apr 12 15:05:10 and at least one more I cannot find now Apr 12 15:13:31 rburton: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-March/037660.html Apr 12 15:15:06 how much memory do I need to bake webkit-efl ? Apr 12 15:15:32 4GB + 4GB swap seems to be too little Apr 12 15:16:09 rburton: this is also sysvinit/systemd related http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038052.html Apr 12 15:19:08 void-dev: you probably want more than that, and be prepared for a 30 minute compile even so Apr 12 15:20:16 JaMa: right, we just spoke about that in the general case Apr 12 15:20:40 void-dev: 4G should be enough Apr 12 15:20:57 void-dev: I'm building it on one machine with 2G RAM + 3G swap Apr 12 15:21:03 rburton: yeah, I figured that it is not enough, just was looking for some rough estimate re. size. and compile time isn't the problem (I like coffee), and the OOM is during link stage Apr 12 15:21:23 void-dev: is it for x86-64? Apr 12 15:21:29 void-dev: you can probably turn off the link optimising? Apr 12 15:21:36 JaMa: hmmm, wasn't enough for me, and yes, x86-64 Apr 12 15:21:47 void-dev: ah right, 64bit needs more Apr 12 15:22:03 not sure how much, I'm building 64bit only on machine with 16G or more Apr 12 15:22:06 presumably the problem is that its trying to do a whole-object link to optimise Apr 12 15:24:21 JaMa: rburton: swapon huge swapfile "fixed" it.... need a bigger machine for this Apr 12 15:25:14 void-dev: it's only short peak in mem usage, swapfile is good enough for that Apr 12 15:25:31 void-dev: is 4G a limit imposed by your mobo, or can you go shopping? Apr 12 15:25:41 but yes if you can get better machine then good for you :) Apr 12 15:29:16 rburton: I am currently had the plan for just a small trial run, to confirm it was pilot error (of mine), so I used my laptop Apr 12 15:29:29 ah, fair Apr 12 15:30:15 * void-dev thinks building Tizen IVI / AGL with Yocto take a little longer than expected ;) Apr 12 15:31:05 void-dev: apart from webkit, it's not that bad :) Apr 12 15:31:43 for me, adding webkit almost doubles the build time of a typical image Apr 12 15:31:55 void-dev: are you building webkit-efl from meta-efl layer or some other recipe? Apr 12 15:32:16 * JaMa is building 3 webkit versions :/ (gtk/efl/qt) Apr 12 15:32:29 JaMa: not blink? Apr 12 15:32:38 JaMa: meta-efl Apr 12 15:32:59 JaMa: does webos still build several then? Apr 12 15:33:18 rburton: webos only webkit-webos (qt based) Apr 12 15:33:38 ah, good. i thought it was qt and something else. Apr 12 15:33:40 gtk and efl for SHR (midori and eve browsers) Apr 12 15:36:15 JaMa: btw. the docu (on the web site) on how to build SHR is kind of broken Apr 12 15:36:28 JaMa: but I guess you knew that already Apr 12 15:37:33 no, what's wrong? Apr 12 15:38:41 * void-dev checks if enough RAM's left to start webbrowser Apr 12 15:40:22 JaMa: something about setup script looks for meta-openembedded, but git clone should be made into meta-oe Apr 12 15:40:33 just before Apr 12 15:40:55 void-dev: you mean the manual setup or Makefile way? Apr 12 15:42:09 I don't see meta-openembedded mentioned in http://shr-project.org/trac/wiki/Building_SHR Apr 12 15:42:23 JaMa: yes, the one on http://shr-project.org/trac/wiki/Building_SHR_without_chroot Apr 12 15:42:37 which the other one you mention points to Apr 12 15:43:50 JaMa: http://shr-project.org/trac/wiki/Building_SHR#Manualmethodadvancedusersonly Apr 12 15:44:52 void-dev: I still don't see meta-openembedded there, do you mean that bblayers.conf from common repo expectes meta-openembeded but checkout is in meta-oe? Apr 12 15:46:03 JaMa: or it was the other way around, clone meta-oe from github and setup-env does reference meta-openembedded Apr 12 15:46:06 let me double check Apr 12 15:47:21 fixed Apr 12 15:47:49 that's why Makefile way is recommended, I don't want to maintain the same information on 3 places :/ Apr 12 15:49:32 JaMa: true, luckly I did count myself (at that time) as advanced user and found a workaround Apr 12 16:11:43 Anyone looked into license-filtered sstate distribution? Apr 12 16:12:27 I'm thinking that it'd be good to avoid issues with binary redistribution for certain licenses by also avoiding inclusion of their sstates in any shipped or deployed sstate archives Apr 12 16:12:43 pidge: thoughts? Apr 12 16:15:11 kergoth: I'd be tempted to (ab)use the mechanism we use for the native lsb string insertion Apr 12 16:15:39 ah, shove it into the filename? interesting idea Apr 12 16:16:06 kergoth: then you'd get clear directory separation and could do policy as necessary based on that Apr 12 16:25:06 Hmm, I need to remember to throw together a patch to remove the OVERRIDES mangling from PACKAGES. Think it's still possible to get recursions due to FOO_ referencing ${FOO} Apr 12 16:25:20 RP: it's a good idea, will hav e to play with it if I find the time, thanks Apr 12 16:53:19 kergoth: so, I'm trying to figure out why a function defined in one class inherited at the global level might not be visible from another class also inherited at the global level (both with INHERIT += ) ... any suggestions? Apr 12 16:53:33 I can push the changes as a patch if that helps Apr 12 16:57:58 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=paule/lconf-fix&id=23b1ce7d5848e471e09ef0078186de47aeb8a3a3 Apr 12 17:05:43 bit of a difficult patch to look at without context I know... Apr 12 17:20:49 kergoth: nm - issue was the function name ending with _poky meaning it treated that as an override Apr 12 17:20:56 :/ Apr 12 18:19:46 any idea why linux-yocto-3.8.do_populate_sysroot seems to take forever now? Apr 12 18:20:08 strace of python process doing it is full of ESPIPE (Illegal seek) Apr 12 18:20:24 and is running for 5-10 minutes already Apr 12 18:32:56 and still running... Apr 12 18:45:38 It seems dylan and master are not in sync anymore Apr 12 18:51:48 hurray, just finished Apr 12 18:52:03 35minutes still looks wrong Apr 12 18:52:31 heh and I probably know why... Apr 12 18:52:32 /OE/shr-core/tmp-eglibc/sysroots/spitz/usr/src/kernel/ipc/util.h Apr 12 18:52:32 Matched in manifest-spitz-linux Apr 12 18:53:12 I've changed PREFERRED_PROVIDER and it was looking for sstate owner of every single header and file staged by kernel Apr 12 18:54:12 doing that 18439 times probably takes like 35 minutes Apr 12 19:52:02 khem: do you remember me reporting that RPROVIDES didn't work for openssh-sshd-systemd? Apr 12 19:52:21 khem: new warning seems to explain that ;) WARNING: Variable key RPROVIDES_${PN}-sshd (sshd) replaces original key RPROVIDES_openssh-sshd ( openssh-sshd-systemd). Apr 12 19:53:30 okay i have a distro which needs to work for both x86 and arm boards but when i add the "kernel" and "kernel-" packages only to the x86 builds it does not seem to respect the PREFFERED_PROVIDER_virtual/kernel = "linux-yocto" line in th emachine configuration--that is, it adds both the kernel recipe i am working on which uses a different SRC_URI and does not inherit from linux-yocto Apr 12 19:53:35 Ahh.. RP merged the patch.. Apr 12 19:54:47 waynr: you'll need to use machine overrides or set the value from the machine config in that case Apr 12 19:55:21 waynr: i.e. the former would be PREFFERED_PROVIDER_virtual/kernel_yourx86machine = "linux-yocto" Apr 12 19:55:57 and similar to set the provider for the arm machine Apr 12 19:56:03 well the PREFERRED_PROVIDER is already being set from the machine configuration Apr 12 19:56:55 my brain is turning to mush right now... Apr 12 20:01:21 okay trying the build over in a clean build directory Apr 12 20:07:54 fray: it's quite useful, thanks for that Apr 12 20:08:12 fray: sending 5 patches to fix issues found by that Apr 12 20:19:00 JaMa -- when we figured out what was wrong.. I was at least happy that oe-core didn't have a huge number of them Apr 12 20:23:57 okay i got just the yocto kernel installed but i had to remove the "kernel" and "kernel-image" from the x86-specific packagegroup Apr 12 20:25:32 somehow the packagegroup "Depends:" in var/lib/opkg/lists/oe-all was getting dependencies named "kernel-" and "kernel-image-" where customerkernelversionnumber happens to be 3.2.21 Apr 12 20:38:23 fray: I've found most of them in meta-systemd, which makes sense, it's easier to use different key format in .bbappend then in the same .bb file Apr 12 20:47:15 rburton: still interested in hunting upgrade-path issues? Apr 12 20:47:16 * check_data_file_clashes: Package busybox-syslog wants to install file /etc/default/busybox-syslog Apr 12 20:47:20 But that file is already provided by package * busybox Apr 12 20:48:46 rburton: nvm, looks like caused meta-oe .bbappend Apr 12 21:39:13 JaMa: sorry it merged as late. I thought it was worth merging as it does warn about real issues Apr 12 21:51:42 RP: np, I'm glad you did Apr 12 21:51:55 still in time to fix other layers before branching dylan there Apr 12 21:55:28 JaMa: RP: what happened? Apr 12 21:55:56 bluelightning: the bitbake expandkeys warning patch I merged relatively rencently Apr 12 21:58:29 RP: just wondering if we need to add a note in the migration info... Apr 12 21:59:21 It would be a good idea to explain to someone what that warning means.. and of course how to fix it Apr 12 21:59:33 (i.e. a release note) Apr 12 22:43:04 halstead: ping Apr 12 22:43:23 the korg mirror isn't updating :/ Apr 12 22:44:19 fray: the migration section of the manual is kind of an extended set of release notes (but excludes known issues)... I'll talk to scottrif about adding that Apr 12 22:45:25 sounds good to me Apr 12 22:45:57 i see x32... Apr 12 22:46:06 did anything come of that after the trolling died down? Apr 12 22:46:37 nitink: ^ Apr 12 22:46:53 I believe the code got checked in.. but the way it's been explained to me, it's still too experiemental for 'real' world use Apr 12 22:47:02 but my take is that with a bit more work, it should be usable Apr 12 22:47:11 (I don't know the YP status though) Apr 12 22:47:48 well ive been interested in adding a x32 yocto buildbot / support to a different foss project, but everythings been to unusable for a long time Apr 12 22:47:56 for supposed "gains" Apr 12 22:48:05 * Daemon404 goes back to keeping an eye out from the sidelines Apr 12 22:48:25 My suggestion (if it's not in 1.4).. ask in a couple weeks at the beginning of the 1.5 work.. Apr 12 22:48:47 I think it's at the point where it can be stabilized and at least brought to a usable.. even if not product ready capability Apr 12 22:48:51 well i dont specifically mean poky or oe Apr 12 22:48:56 but x32 in general Apr 12 22:48:58 its env Apr 12 22:49:00 libs, etc Apr 12 22:49:14 I was under the impression that kernel, libc and compiler support were all there --if-- you use the absolute latest versions of each Apr 12 22:49:51 we'll see Apr 12 22:51:00 with a new enough kernel i can probably chroot to poky's x32 sysroot fairly easily Apr 12 22:52:22 ls Apr 12 22:52:24 oops Apr 12 23:31:23 RP: sorry I haven't noticed it's in multilib.conf Apr 12 23:31:25 thanks **** ENDING LOGGING AT Sat Apr 13 02:59:58 2013