**** BEGIN LOGGING AT Tue Feb 12 02:59:58 2013 Feb 12 08:39:11 Is there a different in the image generation if I put IMAGE_FSTYPES += "ext3 cpio.gz" and then boot the different images? If i boot the cpio (runqemu qemux86 nographic ramfs) i got no console and some /dev nodes seems to be missing all works with the ext3 image. Confused Feb 12 08:40:30 neg: yes, the boot process with an initramfs and a normal root filesystem is slightly different. Feb 12 08:40:52 neg: for example, if you have CONFIG_DEVTMPFS_MOUNT, and you use a normal root filesystem, devtmpfs is automatically mounted in /dev by the kernel before starting init. Feb 12 08:41:21 neg: the default init application in an initramfs is /init, while it is /sbin/init in a normal root filesystem Feb 12 08:41:24 etc. Feb 12 09:19:18 morning all Feb 12 09:25:49 hey bluelightning, all good? Feb 12 09:26:09 hi eFfeM_work Feb 12 09:26:20 eFfeM_work: not too bad, and yourself? Feb 12 10:04:49 bluelightning: I'm fine Feb 12 10:05:08 wrapping up and transferring all kind of things. Feb 12 10:17:25 eFfeM_work: the transition time can be one of the busiest times can't it... when I left my last job on the last day I worked right up until the office closed Feb 12 10:28:22 bluelightning: I'm hoping to plan better Feb 12 10:28:31 last day is probably feb 25 Feb 12 10:37:56 kos_tom: ok thanks, I'm trying to figure it out :) but a bit hard to debug when I can't spawn a gettty on /dev/ttyS0 since the node do not exists Feb 12 10:38:07 neg: indeed. Feb 12 10:38:43 neg: in Buildroot, at /init, we install a small shell script that mounts devtmpfs and starts the normal /sbin/init, so that the two initialization processes (with initramfs and without) are a bit more similar. Feb 12 11:13:03 hi, could anyone suggest a way to insert an entry in /etc/modules on image creation? I'd like a kernel module to be loaded by default Feb 12 11:23:57 kos_tom: that is a good idea, thanks Feb 12 11:35:26 What is the best way to manage such a chnage, in a .bb recipie or is there a better way to modify the content of a rootfs file? Feb 12 12:37:21 hi ! question on src.rpm creation with the ARCHIVER_MODE[type] = "srpm" : Feb 12 12:37:43 why are the resulting "src.rpm's" not recognized by rpm as such: Feb 12 12:37:44 poky/build/tmp/deploy/sources/deploy-srpm/srpm> rpmbuild --rebuild zlib-1.2.7-r0.src.rpm Feb 12 12:37:44 Installing zlib-1.2.7-r0.src.rpm Feb 12 12:37:44 warning: InstallSourcePackage at: psm.c:238: Header V4 DSA/SHA1 Signature, key ID 8e7f3d37: NOKEY Feb 12 12:37:44 error: source package expected, binary found Feb 12 12:37:45 error: zlib-1.2.7-r0.src.rpm cannot be installed Feb 12 12:37:59 looks fishy Feb 12 13:40:06 q: howto force rebuild of single package? I'm fixing a build problem, did manual compilations in devshell etc. Now build is stuck at do_install of the broken package which I'd like to rebuild again from sources. Feb 12 13:42:02 mcfrisk: bitbake -f -c compile Feb 12 13:42:02 mcfrisk, bitbake -c clean Feb 12 13:42:03 ? Feb 12 13:48:26 Zagor & markos_: thanks, those helped. Didn't find that instruction with google though. Feb 12 14:52:57 rburton, did anyone see my patch for make go by? Feb 12 15:53:30 * kergoth perf sanity checks bb.compat.Pool based parsing, based on the old pool we used to use before the switch to futures and subsequent switch to a homerolled pool Feb 12 15:59:51 Song_Liu: YPTM: Sean has joined the call Feb 12 16:00:42 YPTM: belen joined the call Feb 12 16:00:43 YPTM: welcome to the technical team meeting, please let me know who's on the bridge. Feb 12 16:00:45 YPTM: Scott Rifenbark joined call Feb 12 16:00:46 YPTM: Laurentiu Palcu joined Feb 12 16:00:48 YPTM: Paul Eggleton is on the call Feb 12 16:00:58 YPTM: Kevin Strasser is here Feb 12 16:00:59 YPTM: Richard is here Feb 12 16:01:08 * darknighte waves Feb 12 16:01:10 YPTM: Tom Z on the call Feb 12 16:01:18 YPTM: Amit is here Feb 12 16:01:27 YPTM: Belen is here Feb 12 16:01:56 YPTM: Cristian Iorga is present Feb 12 16:02:28 YPTM: Bruce Ashfield on the call. Feb 12 16:02:31 YPTM: nitin is on the bridge Feb 12 16:02:37 YPTM: Any opens? Feb 12 16:03:14 YPTM: jzhang join the call and will drop early Feb 12 16:03:29 YPTM: Michael Halstead is on the call. Feb 12 16:03:48 yptm: ross joined Feb 12 16:04:17 YPTM: Denys is here too Feb 12 16:05:16 YPTM: saul is here now Feb 12 16:06:25 YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status Feb 12 16:06:37 YPTM: Chris Larson here now too, running a bit late this morning Feb 12 16:07:48 YPTM: Corneliu joined Feb 12 16:10:13 YPTM: Fahad Usman joined Feb 12 16:14:31 on track for a fast meeting Feb 12 16:14:52 https://wiki.ctest.yoctodev.org/wiki/Sample_Summary_Report Feb 12 16:15:05 https://wiki.ctest.yoctodev.org/wiki/Sample_Extended_Report Feb 12 16:16:46 scottrif: had to jinx us didn't you! ;) Feb 12 16:17:09 :) still lots time to shave Feb 12 16:18:27 Song, we just lost connection to the bridge Feb 12 16:18:42 do you have issues with the bridge? Feb 12 16:18:50 same here Feb 12 16:18:57 lost connection Feb 12 16:19:00 same here Feb 12 16:19:03 okay, we'll just redial Feb 12 16:19:42 YPTM: rejoined Feb 12 16:22:35 YPTM: Björn joined Feb 12 16:25:25 halstead: sounds like good improvements, thanks! Feb 12 16:28:06 YPTM: thank you all for joining the meeting. Have a nice day/evening Feb 12 16:29:24 Hmm, I think we need a way to document packageconfig entries. we can't use a doc flag, since the entries are already flags Feb 12 16:29:30 thoughts? Feb 12 16:43:33 kergoth: maybe _doc and ignore varflags prefixed with _? Feb 12 16:43:54 kergoth: somehow I thought rburton had already done something like that but I can't find it so I must be imagining things Feb 12 16:44:01 no, i didn't Feb 12 16:44:19 but i was also thinking something along the lines of PACKAGECONFIG[_doc_foo] = "blaa blaa about foo" Feb 12 16:44:37 actually, _-prefixed symbols might magically disappear Feb 12 16:44:39 so don't do that Feb 12 16:44:58 i *did* fix some stuff where internal flags weren't hidden Feb 12 16:45:23 PACKAGECONFIG[doc_foo] = doesn't sound like a terrible idea Feb 12 16:45:23 rburton: ah, I guess that's what I was thinking of... where in the code was that fixed? Feb 12 16:45:39 erm Feb 12 16:45:42 in retrospect i wish we had proper dictionaries so we coudl use flags as intended Feb 12 16:45:46 in data_smart iirc? Feb 12 16:48:26 rburton: ah, right... so internal (_ prefixed) flags won't be returned by getVarFlags() Feb 12 17:06:51 PACKAGECONFIGDOCS[xxx] ? Feb 12 17:07:29 rburton: you recall correctly :) Feb 12 17:08:24 RP: that's a bad sign :) Feb 12 17:08:48 rburton: it is? Feb 12 17:10:34 yes. i try and purge any knowledge at that level on a weekly basis. Feb 12 17:25:03 RP: is there any plans to provide patchwork for other layers? Feb 12 17:25:20 RP: I would like to have it for meta-fsl-arm if possible Feb 12 17:25:45 otavio: probably just a case of talking to the OE admins Feb 12 17:25:53 otavio: try khem? Feb 12 17:26:36 RP: will do Feb 12 17:27:57 RP: thx Feb 12 17:44:34 what's the suggested way to autoload a kernel module on system boot? tried adding module_autoload_%s in my kernel's bbappend recipe, but that didn't seem to work Feb 12 17:45:17 markos_: that should work if you also add that kernel module to RDEPENDS so it's installed in image Feb 12 17:45:42 the module is already in the image, I can manually modprobe it after boot Feb 12 17:45:55 does it have any - or _ in filename? Feb 12 17:46:00 no Feb 12 17:46:29 markos_: see if it has postinst and extra file for /etc/modprobe in .ipkk Feb 12 17:46:36 JaMa: was there a new version of the rm_work patch? Or have I missed something? Feb 12 17:47:30 RP: I've updated it locally but haven't sent it yet Feb 12 17:47:42 JaMa: ok, fair enough :) Feb 12 17:47:55 haven't tested it properly because of travel.. Feb 12 17:48:01 JaMa, there is no file in /etc/modprobe.d if you mean that Feb 12 17:49:40 markos_: sorry /etc/modules-load.d/module-name Feb 12 17:49:59 JaMa, no such directory :-/ Feb 12 17:50:05 should I populate that? Feb 12 17:50:33 markos_: kernel-module-foo should create it when module_autoload_foo = "1" is set Feb 12 17:51:05 does it have to be 1? I thought I had to set it to the name of the module Feb 12 17:51:10 s/= "1"/= "foo"/g Feb 12 17:51:13 ah right :) Feb 12 17:51:29 and what about postinst? Feb 12 17:51:38 there should be modprobe foo in postinst Feb 12 17:51:53 /etc/rpm-postinsts? Feb 12 17:52:58 I'm not using rpm, sorry Feb 12 18:08:22 JaMa, is there a possibility that this functionality is tied to a certain packaging backend (eg ipkg?) Feb 12 18:09:07 actually, I'm using danny, I hope it's not too old a version for that? Feb 12 18:26:39 hi. i'm trying to install a dev-package to the rootfs via IMAGE_INSTALL_append. the rpm exists in the deploy directory, but bitbake says "ERROR: Nothing RPROVIDES 'libc6-dev'", the same goes for the dbg pkg. how can this be done? Feb 12 18:31:11 schramae: I think you need to use eglibc-dev and eglibc-dbg there Feb 12 18:31:29 i.e. the name used in IMAGE_INSTALL is the name *before* debian renaming Feb 12 18:32:45 bluelightning: thanks, i'll try. are there some high-level docs, describing this and other internals of the buildsystem? i have been fiddling around with the pkg names for quite a while now Feb 12 18:33:30 schramae: hmm... well we do have the manuals, I'm not sure how high-level you would rate them, but they are fairly comprehensive Feb 12 18:34:02 https://www.yoctoproject.org/documentation/current Feb 12 18:35:10 bluelightning: thx. i went though most of these a while ago, maybe i should do it again Feb 12 18:38:23 bluelightning: i just tried, same error for eglibc6-dev. as said, the deploy dir for the RPMs contains all of libc6{-dbg,-dev}, but dbg and dev can't be built acc. to bitbake Feb 12 18:38:41 schramae: it's eglibc-dev not eglibc6-dev Feb 12 18:40:46 bluelightning: sry, my fault. it's building now, let's see what qemu says Feb 12 18:42:38 bluelightning: I have an oddball problem, perhaps you can direct me how I might fix it. Feb 12 18:42:52 libtool does not depend on sed Feb 12 18:43:19 It uses the hosts /bin/sed for the first build, but if you have sstate and such and later libtool needs an update for any reason and sed is in the sysroot. Feb 12 18:43:22 It uses that one. Feb 12 18:43:43 And it will get an internal path like: SED="/space/jw/5/small/qemux86/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed" Feb 12 18:44:12 I figured oh... why not just add an RDEPENDS to sed to solve, but that doesn't work, and you cannot build sed first either. Feb 12 18:44:23 jwessel: do you mean libtool-native ? Feb 12 18:44:28 or libtool Feb 12 18:44:34 yes, the libtool-native, sorry about the confusion. Feb 12 18:44:55 and adding the sed-native is what I was attempting, but that didn't work. Feb 12 18:45:19 Certainly we could for /bin/sed upon the libtool-native, but I wasn't sure that was right either. Feb 12 18:45:41 At least that will stop these screwball build failures where auto-tools come from sstate, but sed-native isn't there. Feb 12 18:45:56 jwessel: I think libtool-native is one of early packages Feb 12 18:46:04 there is a bootstrap look issue Feb 12 18:46:07 ig you depend on sed Feb 12 18:46:13 or rather sed-native Feb 12 18:46:58 But when you put sed in the libtool-native DEPENDS it causes a circular dependency. Feb 12 18:46:59 jwessel in the past I've solved this by hard coding in the script(s) SED="sed" or SED="/usr/bin/env sed" Feb 12 18:47:00 just use `/usr/bin/env sed` ma ybe Feb 12 18:47:31 ah s/look/loop I should have said Feb 12 18:47:41 yes using env sed is right Feb 12 18:48:14 If that is what the consensus is I'll make patch. I just need something to stop the random build failures on libtool :-) Feb 12 18:48:23 Rather failure while using libtool-native Feb 12 18:48:39 please do Feb 12 18:48:39 I'd say hard code the values to something reasonable and known to work Feb 12 18:49:45 fray: In that case, it is either just use /bin/sed, or the env thing. Feb 12 18:50:30 The only concern I had with the env thing, is that of the parallelism. We might end up with something that switches over to the sysroot-native sed when it suddenly comes available. Feb 12 18:50:51 -if- we might build sed-native, then /usr/bin is better.. (I think) but it does open a small window where something might try to call sed and we're installing it into the sysroot Feb 12 18:50:59 And then have some crazy hard to reproduce build failure. Feb 12 18:52:03 Since 90% of the time, libtool is always using /bin/sed since that is how it is boot strapped, perhaps /bin/sed is the safe bet here. Feb 12 18:52:32 I think you can then just ask for /bin/sed always Feb 12 18:52:51 CACHED_CONFIGUREVARS += "ac_cv_path_SED=/bin/sed" will do it Feb 12 18:53:03 khem: Correct. Feb 12 18:53:04 RP: https://github.com/kergoth/bitbake/compare/parse-compat-pool - needs more testing, but so far so good here Feb 12 18:54:06 * kergoth tweaks Feb 12 18:55:44 RP: no significant difference in parse time between that and the homerolled one, but it does cut down the code Feb 12 19:00:51 After that libtool thing bit me for the 3rd time in 2 weeks I thought I better track it down. Feb 12 19:00:57 khem: Thanks! Feb 12 19:05:21 JaMa: to cope with oe-core systemd the -systemd packages from meta-systemd needs to go away and merge into package proper for upgrade path I am adding RPROVIDES_${PN} = "${PN}-system" is that enough ? or do we also need RREPLACES Feb 12 19:06:14 rprovides will satisfy the dep, but won't get rid of the already installed package, which means the two packages will conflict file wise Feb 12 19:06:21 probably need both conflicts and replaces Feb 12 19:06:28 * kergoth isn't 100% sur eon that though :) Feb 12 19:07:40 yes all 3 are needed at least for opkg Feb 12 19:08:08 khem: but e.g. dbus in oe-core doesn't do it and rburton was against adding it Feb 12 19:08:17 khem: so I've already gave up on upgrade path Feb 12 19:08:57 and my binary feed is still using danny Feb 12 19:34:01 hey I've got a patch thats of the format /home/mhatle/git/project/oe-core/build/tmp-eglibc/work/x86_64-oe-linux/eglibc/2.17-r3/eglibc-2.17/libc/csu/../sysdeps/x86_64/crti.S ... is there a simple python/oe function to remove the "..".. but more to the point resolve that file and give me the -actual- path, even if it's a link? Feb 12 19:36:00 patch - path.. anyway.. Feb 12 19:39:02 fray: You mean the equivalent of readlink -f ? Feb 12 19:39:29 Hmm.. Feb 12 19:39:38 http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac <- Look at the part where there is a python function called realpath Feb 12 19:39:47 I don't know if bitbake has a service function like that or not. Feb 12 19:39:56 ya.. that looks like what I need Feb 12 19:40:17 ahh perfect.. Feb 12 19:40:18 Might be a good candidate for the bb service class, if the maintainers are ok with that. Feb 12 19:40:58 ya.. realpath looks like what I want.. Feb 12 19:41:07 And of course it is a heck of a lot less expensive than forking to get the answer ;-) Feb 12 19:41:17 yup Feb 12 19:55:05 question on src.rpm creation with the ARCHIVER_MODE[type] = "srpm" Feb 12 19:55:43 I see this with the resulting src.rpms: "error: source package expected, binary found" Feb 12 19:56:12 which RPM are you using to 'install/extract' it? Feb 12 19:56:26 Normally you'd use 'rpm2cpio' to extract it for viewing.. Feb 12 19:56:50 the srpm packages constructed are just containers anyway, they will not actually rebuild outside of the build system.. Feb 12 19:57:05 the goal is to provide the source in a common format for people who are expecting SRPM.. Feb 12 20:00:30 I want to use rpmbuild --rebuild against them Feb 12 20:00:55 Hi all, I'm try my hand at using the adt with the Eclipse plugin. My sysroot has a file /usr/include/test.h but Eclipse cannot find it. When I look at the project properties, I see under C/C++ General->Paths and Symbols the the include directories are all on the "host" (i.e., /usr/include not /path/to/sysroot/usr/include). Feb 12 20:00:57 the mechanism used seems to produce a "binary container" instead of a full src.rpm Feb 12 20:01:09 is that the case ? Feb 12 20:01:21 Shouldn't it be pointing to the directories under the given sysroot? Feb 12 20:02:10 dl9pf_ you can't.. simple as that Feb 12 20:02:27 if you use rpm2cpio and inspec the .spec file.. you'll see that it doesn't have enough to rebuild them Feb 12 20:02:43 (and it's nearly impossible to provide enough instructions -- the build systems are just "different") Feb 12 20:02:43 otherwise, if I have headers that are part of my yocto rootfs but not part of my host system, I won't be able to use the ADT to develop using them? Feb 12 20:05:53 Or am I misunderstanding something? Feb 12 20:08:36 Whatever you are doing should be passing to the compiler that your sysroot is the appropriate path for what you are building.. i.e.: Feb 12 20:08:55 /opt/poky/1.4/sysroots/x86_64-poky-linux Feb 12 20:09:10 I am not familar with the ADT though to be able to help with that. Feb 12 20:09:54 yeah, when it runs external tools it does that, I'm just trying to figure out how to use the editor Feb 12 20:10:03 I'll keep playing around with it and see if I can figure something out Feb 12 21:06:47 halstead: ping Feb 12 21:09:00 scottrif, pong Feb 12 21:09:49 halstead: hi - do you know any recommended sites for easy set up of gitolite/cgit etc.? Feb 12 21:10:11 halstead: want to reference them in a section Richard helped write Feb 12 21:10:12 No. Feb 12 21:10:39 scottrif, Probably the primary docs for those projects are the best resource. Feb 12 21:10:44 halstead: ok - I will just google around and see if I can find something Feb 12 21:11:50 scottrif, http://sitaramc.github.com/gitolite/master-toc.html and http://hjemli.net/git/cgit/tree/README are what I used. Feb 12 21:12:07 halstead: great.. thanks! Feb 12 21:15:08 kergoth: I wondered if we could do that, looks good Feb 12 21:39:52 fray: hmm why ... if I take a yocto system with rpm packaging why should I not be able to do an rpmbuild --rebuild ? (I see that the specfiles are somewhat bogus) but I think the question is still valid. Feb 12 21:40:22 the OE build environment does not use the spec file or RPM to perform the build.. Feb 12 21:40:31 fray: clear Feb 12 21:40:37 Some of the operation that the OE environment performs can not be translated into 'spec' operations.. Feb 12 21:40:59 so the best we can do is document what was done in the .spec file Feb 12 21:41:01 which ? Feb 12 21:41:18 package splitting, split/strip of debug info.. Feb 12 21:41:26 some configure steps are done in python Feb 12 21:41:27 etc.. Feb 12 21:42:15 hmm ... debuginfo / split/strip is iirc all defined as macro in rpm, so override is possible ... package splitting is possible Feb 12 21:42:25 no it's not Feb 12 21:42:26 ok, fancy configure steps left Feb 12 21:42:43 look at all of the code in meta/classes/* that can't be replicated in the RPM environment Feb 12 21:43:33 if you think it can, we'll happily accept patches for that work.. but we've not been able to come up with a creative solution that produces a buildable spec file Feb 12 21:50:26 hmm _ from my noob understanding, we'd just need do_configure and do_compile (considering we're rebuilding in the target and have rpm macros setup properly) Feb 12 21:50:50 ok pre/post scripts get tricky Feb 12 21:50:58 you need, unpack, patch, configure, compile, install and package operations.. Feb 12 21:51:14 the package operations are the ones that split up the components, verify and manipulate the elements automatically.. Feb 12 21:51:41 no ... unpack not as we've a tarball, patch is handled by rpm (as we ave a accumulated patch file) Feb 12 21:51:41 the unpack/patch operations, for the most part work like they do in RPM.. but RPM doesn't have some of the code to adjust the patch levels that OE does.. Feb 12 21:51:55 configure yes, compile, yes install , yes Feb 12 21:52:07 configure has python steps, compile and install can have them, but don't always.. Feb 12 21:52:23 however the shell steps they run DO use bitbake variables and environment commands that won't be avaible in the RPM environment.. Feb 12 21:52:50 so what if python and bitbake is available in the environment ? Feb 12 21:52:51 i.e. do_install uses '${S}' for the soruce directory, '${B}' for the build directory and '${D}' for the destination directory.. Feb 12 21:52:59 each fo them have an equivalent in RPM.. but there are a lot more then that.. Feb 12 21:53:17 it's not possible to map all of them.. Feb 12 22:00:35 dl9pf_: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass <-- have you actually seen how much work happens when autotools configuring a package? Feb 12 22:04:39 nothing I haven't seen in principle in a %configure macro ... so hmm, can we print out what each step would do ? Feb 12 22:05:43 dl9pf_: you're welcome to give it a go, but i think everyone else agrees its almost certainly not going to work Feb 12 22:08:02 Anyone have any experience with using the Eclipse plugin with ADT? I have a question about include paths. It looks like when I create a new C/yocto project, the include paths are all system paths (e.g., /usr/include instead of /path/to/sysroot/usr/include) Feb 12 22:09:35 ah, wait; I did a 'clean' and it added them Feb 12 22:52:31 If anyone's getting "Tried to stat..." errors from pseudo, yes I know about them, and I just sent the fix out for review. Sorry! Feb 12 23:48:07 So I'm trying to run bitbake and I'm getting an unusual error Feb 12 23:48:23 "NOTE: Your conf/bblayers.conf has been automatically updated. Please re-run bitbake." Feb 12 23:48:41 and I rerun bitbake and get the same error Feb 12 23:49:29 so I opened a new shell, started a new build tree, and get the same error (and errorrs about unable to create /../../var/pseudo (I think because bitbake -e also fails) Feb 12 23:49:32 any ideas? Feb 13 00:35:43 Hum... seems I had a bad distro variable Feb 13 00:37:08 how do you 'subclass' a distro? Feb 13 00:38:18 or just change it'ss name? **** ENDING LOGGING AT Wed Feb 13 02:59:58 2013