**** BEGIN LOGGING AT Fri Sep 14 02:59:59 2012 Sep 14 07:12:26 JaMae: do you have another second? Sep 14 07:13:19 morning zecke Sep 14 07:20:03 morning Sep 14 07:23:12 i added a kernel recipe to my layer (linux-2.6.32.bb), and I set PREFERRED_PROVIDER_virtual/kernel = "linux" and PREFERRED_VERSION_linux = "2.6.32" but bitbake still wants linux-yocto, and it thinks all recipies have a prefered version of 2.6.32, do i have to rename my recipe ? Sep 14 07:27:34 afournier: I'm guessing PREFERRED_PROVIDER_virtual/kernel is being set somewhere else and that is overriding your setting Sep 14 07:27:46 i set it in my local.conf Sep 14 07:27:49 to confirm: bitbake -e | grep PREFERRED_PROVIDER_virtual/kernel Sep 14 07:29:35 gm bluelightning Sep 14 07:29:46 hi woglinde, all Sep 14 07:30:16 bluelightning: it tells me this PREFERRED_PROVIDER_virtual/kernel="linux" Sep 14 07:31:32 it also tells me PREFERRED_VERSION="2.6.32" even if i wrote PREFERRED_VERSION_linux="2.6.32" Sep 14 07:31:38 it looks like a bug Sep 14 07:32:03 and it was working with PREFERRED_VERSION_linux-yocto Sep 14 07:32:04 oh, wait Sep 14 07:32:05 no Sep 14 07:32:38 I know what's happening - "linux" is in OVERRIDES already (from TARGET_OS) Sep 14 07:32:51 thus it will be applied to all recipes Sep 14 07:32:58 ah ok Sep 14 07:33:06 so i should rename my kernel recipe Sep 14 07:33:32 it might help perhaps, but I don't understand why it wouldn't be selected as the preferred provider, that's a different issue Sep 14 07:33:34 I have some non-standard licenses I wish to use, basically licenses for our internal source code. How can I add generic license files for them? I tried making a folder files/licenses with a file named the same as the license in our layer. Then I added the path ${LAYER}/files/licenses to LICENSE_PATH in local.conf. However, this still gives me the annoying warning about no generic license file exists Sep 14 07:36:01 woglinde: hey Sep 14 07:36:11 woglinde: do you remember anything about /var/volatile? Sep 14 07:40:50 yes Sep 14 07:40:56 its vot tmp files Sep 14 07:41:09 and yes there were some problems with dbus Sep 14 07:41:18 generating wrong dirs Sep 14 07:41:19 woglinde: I am using meta-systemd and no one creates /var/volatile/run, /var/volatile/lock... Sep 14 07:41:49 woglinde: so /var/log points to -> volatile/log but only initscripts-1.0 create the dirs Sep 14 07:41:57 yes Sep 14 07:42:04 or some recipes in post-inst Sep 14 07:42:37 woglinde: any idea how other users of meta-systemd resolve it? Sep 14 07:45:32 hm Sep 14 07:45:45 not really Sep 14 07:45:52 I fixed dbus locally Sep 14 07:47:11 syslog and network.service don't start properly because of the wrong dirs Sep 14 07:47:30 woglinde: does oe-core use /var/log -> /var/volatile/log symlinks? Sep 14 07:47:38 * zecke heads to search for various versions of base-files Sep 14 07:48:15 zecke hm you dont use journald? Sep 14 07:48:48 he should use zecked :) Sep 14 07:49:14 woglinde: well, syslogd is started for now and it should be able to write to /var/log Sep 14 07:49:35 woglinde: and ifupd should be able to write to /var/run/ifstate (if it feels like doing it) Sep 14 07:51:14 zecke: I notice that meta-angstrom bbappends base-files and sets volatiles = "" Sep 14 07:51:22 does that have anything to do with it? Sep 14 07:52:29 bluelightning: you bet. :) Sep 14 07:52:36 hi stefan Sep 14 07:52:52 hi woglinde :) Sep 14 07:52:59 zecke: I hope that doesn't mean meta-systemd comes non-functional out of the box... Sep 14 07:53:37 bluelightning: this makes basefile not create the symlinks.. but it would mean that /var/log is persistent (which poky assumes not to be the case as from denzil it started to use the busybox-syslogd file backend) Sep 14 08:00:21 morning silvio Sep 14 08:00:41 morning afournier Sep 14 08:00:51 morning all Sep 14 08:03:35 hi silvio Sep 14 08:06:06 ho woglinde Sep 14 08:06:11 hi woglinde Sep 14 08:50:11 hi there! Sep 14 08:51:43 I am using bitbake to build some own recipes... now I have to provide credentials while fetching on some git-repositories. Is there a recommened way to pass credentials to the git-fetcher in bitbake? Sep 14 08:54:39 same as on commandline Sep 14 10:24:34 Hello Sep 14 10:30:23 I'm trying to build node 0.8.8 for the beaglebone. Sep 14 10:30:47 I can build the package but I've got the following error: Sep 14 10:31:03 WARNING: For recipe nodejs, the following files/directories were installed but not shipped in any package Sep 14 10:31:46 And I've got a list of many files, including /usr/lib/node_modules/npm. Sep 14 10:31:54 maybe check your digit Sep 14 10:32:17 lo see all packages "bitbake -s | less" Sep 14 10:32:24 to see all packages "bitbake -s | less" Sep 14 10:32:52 The resulting sysrootfs bz2 archive does not contain anything, including /usr/bin/node (which was NOT mentioned in the non-shipped files) Sep 14 10:34:32 nodejs :0.8.8-r0 Sep 14 10:35:18 erwin, sorry I m not so skilled I can t help u more :( Sep 14 10:35:23 silvio: the default nodejs is 0.6.20. I've changed the recipe to get the 0.8.8 version. Sep 14 10:36:42 silvio: ok, thanks anyway. Sep 14 10:36:51 erwin, I can only say check recipe, I m new of OE wolrd, I have still same problems on other recipes, i m sorry Sep 14 10:37:19 ssame* = I mean similar Sep 14 10:39:13 silvio: the files are staged in nodejs-0.8.8-r0/package, but the rootfs creation process does not seem to copy the files to the rootfs archive Sep 14 10:40:15 If I put explicit install commands in "do_install" section, I can install some files (like /usr/bin/node). But I think it's not the right way to do it. Sep 14 10:41:19 i solved something in this way: Sep 14 10:41:25 install -m 0755 ${S}/lib/*so* ${D}${libdir} Sep 14 10:41:38 install -d ${D}${libdir} Sep 14 10:42:12 or better: Sep 14 10:42:13 morning all Sep 14 10:42:20 do_install() { Sep 14 10:42:20 oe_runmake install INSTALL_ROOT=${D} Sep 14 10:42:20 install -d ${D}${libdir} Sep 14 10:42:20 install -d ${D}${includedir} Sep 14 10:42:20 install -m 0755 ${S}/src/*.h ${D}${includedir} Sep 14 10:42:21 install -m 0755 ${S}/lib/*so* ${D}${libdir} Sep 14 10:42:22 hey pb_ Sep 14 10:42:23 } Sep 14 10:42:25 hi pb Sep 14 10:43:37 erwin, check dirs and permission Sep 14 10:50:58 silvio: I will try with installs. The pb is that there are many sub directories in lib (for node modules). This nodejs thing is using gyp, not vanilla autoconf and it's really a pain. Sep 14 10:51:04 silvio: thanks Sep 14 10:52:28 erwin, I can t help more, let me know Sep 14 10:53:37 erwin you need to set FILES_ right Sep 14 10:53:57 are the mode modules packages are generated dynamic? Sep 14 10:54:18 hi pb and folrian Sep 14 11:02:51 woglinde: FILES_ ? Sep 14 11:04:55 erwin: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-FILES Sep 14 11:06:07 woglinde: there's only one node module (npm) in the nodejs distribution. This module is necessary to install other modules. Sep 14 11:07:05 bluelightning: thanks. So it replaces the explicit "install" commands in do_install. However, there are many js and py scripts installed in the standard node distribution, so some sort of globbing or the likes would be required. Sep 14 11:07:14 erwin: no, not at all Sep 14 11:08:01 bluelightning, hi Sep 14 11:08:49 erwin: install commands or whatever the software package in question does when running "make install" under do_install is one step Sep 14 11:09:45 FILES_ specifies whats in package Sep 14 11:09:52 erwin: then, in do_package the system figures out which files should go into which package, considering the value of FILES_ for each in PACKAGES in the order they appear there - the first that matches gets the file Sep 14 11:09:57 and not whats installed in installdir Sep 14 11:15:39 bluelightning: So there is an "install" phase (do_install), which puts all files in a "staging" location (namely nodejs-0.8.8-r0/package, for example), and a packaging phase that considers FILES_. Sep 14 11:16:40 erwin: yes, except do_install puts files in nodejs-0.8.8-r0/image/ ; it's part of do_package that copies over files to package/ and then from there uses PACKAGES / FILES_ to copy the files to packages-split/ as appropriate Sep 14 11:16:40 bluelightning: if I have include, lib, bin, and share directories that I want to export to the rootfs archive (and these directories have many subdirs), how should I express it concisely with FILES_ ? Sep 14 11:17:23 erwin: the default value of FILES_${PN} already includes those directories; is the recipe setting a different value for FILES_${PN}? Sep 14 11:22:30 bluelightning: there's no FILES_${PN} in my recipe... And I've no image subdir in nodejs-0.8.8-r0, only "package" and "packages-split" Sep 14 11:25:18 Hello guys Sep 14 11:25:48 I was thinking that is it possible to disable any particular sanity test from sanity.bbclass? Sep 14 11:27:20 has anyone tried to build virtualbox guest additions in oe-classic or oe-core Sep 14 11:27:32 specifically interested in the video driver Sep 14 11:41:53 Is there a replacement for DISTRO_PR/DISTRO_REVISION in oe-core? Sep 14 11:57:20 is there a way to remove -Wunused-but-set-variable when compiling a kernel ? Sep 14 11:57:50 yes patch the Makefiles Sep 14 11:58:04 or fix the kernel code Sep 14 11:58:28 let's go for the first one :p too much fixing otherwise... Sep 14 12:41:16 zecke: remind me what was the purpose of that? Sep 14 12:48:52 bluelightning: E.g. I changed DISTRO_FEATURES to remove x11 (things like dbus, etc. do not need to have x11 support) Sep 14 12:49:28 bluelightning: now everthing needs to be rebuild, one used to be able to set DISTRO_PR and then all packages were rebuilt Sep 14 12:55:05 zecke: that's a behaviour of shared state with BB_SIGNATURE_HANDLER = 'OEBasicHash' Sep 14 12:55:52 bluelightning: but how will this influence the package version of *.{rpm,ipk} files? Sep 14 12:55:56 zecke: the system currently has no way of knowing that a recipe looks at part of a variable value and not the whole value Sep 14 12:56:58 zecke: with the PR server enabled you will get PR bumps for all packages that were rebuilt Sep 14 12:57:14 zecke: that is not something enabled out of the box though and it has not been fully tested Sep 14 12:58:18 ;) Sep 14 13:00:07 I think it's a reasonable expectation for the moment that people will not materially change DISTRO_FEATURES and expect to use the same package feeds without manually bumping PR on the affected packages Sep 14 13:01:25 that is one of the steps backwards with oe-core. :) Sep 14 13:07:11 zecke: how is it OK for your packages to be in contradiction to DISTRO_FEATURES if it gets changed? Sep 14 13:08:32 bluelightning: exactly, that is possible today. Sep 14 13:09:08 bluelightning: If I change CFLAGS from -O2 to -O3,I want everything to be rebuilt.. this used to be easily possible. Sep 14 13:09:25 zecke: not with shared state... I recognise it rebuilds more than you might need to, but it will at least rebuild all of the things that need rebuilding Sep 14 13:09:27 it is not possible with oe-core, so it is astep backwards Sep 14 13:10:04 zecke: if they were built with -O2 originally how is it incorrect when that is changed globally to rebuild everything? Sep 14 13:10:21 bluelightning: well, the PR is bumped by either a system that is not fully tested/functional (fail).. or by manually searching users of that distro feature (fail as it is manual) Sep 14 13:10:48 bluelightning: the PR will not be bumped by default. opkg update/upgrade will _not_ result in any update. Sep 14 13:10:55 bluelightning: and as you say the PR server is not ready. ;) Sep 14 13:11:16 zecke: can you explain the use case for changing DISTRO_FEATURES in the way you have done and preserving the package feeds? Sep 14 13:12:40 bluelightning: Past: Everything was rebuilt and the PR/PE of the package was bumped. A run of opkg update; opkg upgrade would re-install everything. Sep 14 13:13:00 bluelightning: today: I change flags, rebuild..opkg update; opkg upgrade.. nothing will be updated Sep 14 13:13:16 (unless I am willing to experiment with the pr server..) Sep 14 13:14:02 I agree that signatures+pr server is the nicer solution.. but it does not appear to be ready yet. Sep 14 13:16:02 bluelightning: no personal complain intended. It is just my assertion of the current state. Sep 14 13:16:29 zecke: it seems like functionality that would be useful for those using the packaging system; you're the first person I've heard request it though... Sep 14 13:16:52 that's given it was available in OE-Classic too Sep 14 13:17:45 zecke: do you regularly make changes to your distro configuration and still want to upgrade existing systems? Sep 14 13:17:52 (using the package manager) Sep 14 13:21:43 bluelightning: well, it should be possible for some systems Sep 14 13:22:03 bluelightning: e.g. at Openmoko we did when introducing the gnuhash Sep 14 13:22:12 bluelightning: angstrom did it several times Sep 14 13:22:38 zecke: out of interest, did you get opkg to reliably upgrade the system in that case? Sep 14 13:23:11 bluelightning: we did (or at least believe we did) Sep 14 13:23:41 ok Sep 14 13:23:45 bluelightning: in general saying "opkg update; opkg upgrade" is easier than explaining customers to setup tftp.. specially when they use windows Sep 14 13:25:00 zecke: sure, I can understand that Sep 14 13:29:28 zecke: looking at how DISTRO_PR was engineered in OE-Classic, without testing it it looks to me like you could just do PR_append = "${DISTRO_PR}" globally and get the functionality back Sep 14 13:31:23 bluelightning: yes, the implementation was really simple. :) Sep 14 13:32:11 well, it could have been simpler as shown above, but then how it is there may have been dependent on the behaviour of bitbake at the time it was originally implemented Sep 14 13:32:43 i.e. there it is adding ${DISTRO_PR} all over the place where ${PR} is referred to Sep 14 14:16:10 morning Sep 14 18:33:37 re Sep 14 18:43:23 gm Sep 14 19:16:39 hmm, why is i2ctools in meta-oe not oe-core? Sep 14 23:46:35 : woohoo! no more phone keyboard for alex Sep 15 00:28:35 hmm, gtk+ failed to build Sep 15 00:30:12 Oh noes! error message? Sep 15 00:31:26 configure is failing Sep 15 00:31:36 I wonder if I shoudl nuke tmp Sep 15 00:33:12 configure: error: Sep 15 00:33:12 *** Cannot link to Accessibility Toolkit. Accessibility Toolkit Sep 15 00:33:13 is required Sep 15 00:33:13 *** to build GTK+ Sep 15 00:33:58 is the accessibility toolkit a part of another package? Sep 15 00:34:28 this used to work Sep 15 00:34:47 I wonder if someone forgot a pr bump or something Sep 15 00:35:33 q\nuking tmp, starting over and going home **** ENDING LOGGING AT Sat Sep 15 02:59:59 2012