**** BEGIN LOGGING AT Tue Mar 24 02:59:58 2015 Mar 24 04:54:07 anyone built libgfortran? Mar 24 08:18:55 ping kergoth Mar 24 09:20:52 hmm, is LOCALCONF_VERSION needed when creating a new distro? I remember picking it up from somewhere but I don't think I remember if it's actually required Mar 24 12:04:45 ping bluelightning Mar 24 12:26:27 ericbutters: bluelightning is at ELC, so he is probably asleep :) Mar 24 12:28:41 belen: i try to do populate_sdk but got errors: http://paste.ubuntu.com/10668530/ -- i built a minimal image using an external toolchain. but baking the sdk does not work. this is on dora Mar 24 12:51:11 ping bluelightning Mar 24 12:51:23 hi ericbutters Mar 24 12:51:27 hi Mar 24 12:51:40 bluelightning: i try to do populate_sdk but got errors: http://paste.ubuntu.com/10668530/ -- i built a minimal image using an external toolchain. but baking the sdk does not work. this is on dora Mar 24 12:55:28 ericbutters: you'll need to talk to whoever maintains the layer you're using to configure the external toolchain (Mentor?); there are dependencies there that are not being correctly handled Mar 24 13:17:49 bluelightning: okay, but how to get more information about this? what are the dependencies? i use bitbake -v -c populate_sdk a-minimal-image and that prints all selected providers: http://paste.ubuntu.com/10668996/ Mar 24 13:18:01 pls note the eglibc-locale Mar 24 13:18:36 i got all the layers from nvidia, but yes, maybe mentor did the toolchain things Mar 24 13:27:45 ericbutters: bitbake -g may possibly be of use tracking things down Mar 24 13:28:23 ericbutters: the other thing to check is if this setup is definitely supported with the dora branch by the folks who supplied it Mar 24 14:12:45 Hello Mar 24 14:14:02 I have a recipe for an image that adds packages to the image : IMAGE_INSTALL += "..."; In the same file, I want to add some packages only for a given target: IMAGE_INSTALL_arm += "..." Mar 24 14:14:16 however, only the packages from IMAGE_INSTALL_arm are built Mar 24 14:14:49 is there a way to have both IMAGE_INSTALL and IMAGE_INSTALL_arm packages built for arm architecture ? Mar 24 14:54:23 ls Mar 24 14:54:52 Whoops, hi all Mar 24 14:55:10 yptm: armin is one Mar 24 14:57:43 YPTM: Ready-Access Number: 8007302996 Access Code: 2705751 Mar 24 14:57:47 YPTM: Stephen on Mar 24 14:57:53 armpit: glad to see your one! How's elc? Mar 24 14:58:20 Huh, I was a bit surprised there was a meeting today w/ ELC on.. Mar 24 14:58:25 YPTM: Mark is on Mar 24 14:58:44 YPTM: Saul is on Mar 24 14:59:04 fray: I think there are many of us that are not at ELC this year. Mar 24 14:59:10 I guess so.. Mar 24 14:59:24 I'm planning to be at the OEDAM meeting end of the week, but couldn't get away for ELC (other commitments) Mar 24 15:00:35 pidge joined Mar 24 15:00:43 YPTM: Bruce is on Mar 24 15:00:55 bluelightning: do you know how I could best determine who creates the gpg signatures on rpm packages? I mentioned it last week, and you said you've no idea where these sigs come from... Mar 24 15:01:01 fray where are you ? Mar 24 15:01:08 currently.. MSP area.. ;) Mar 24 15:01:14 k Mar 24 15:01:14 https://lists.yoctoproject.org/pipermail/yocto/2012-November/010766.html Mar 24 15:01:18 fly into Oakland around 6pm Thursday Mar 24 15:01:23 jaeckel: I'm not sure, I'm afraid... Mar 24 15:01:27 that's what I found as well, so I'm not the first person who wonders Mar 24 15:01:33 YPTM: Richard joined Mar 24 15:01:53 the built in (RPM) package signatures are self created when each package is generated.. Mar 24 15:02:05 RPM5 does this automatically to improve the ability to detect a corrupt package.. Mar 24 15:02:24 you can add your own (trusted) signatures to RPM packages -after- they've been created by the system, using hte 'rpmsign' tool.. Mar 24 15:02:41 fray: thanks alot Mar 24 15:03:30 YPTM: ross joined Mar 24 15:03:36 interesting... we might want to document that somewhere Mar 24 15:03:39 that should be documented somewhere, because I thought it's done somewhere in yocto where I can just hook in and replace the key Mar 24 15:03:52 not as far as I know.. Mar 24 15:04:04 I looked into adding that ability a while back, and decided it wasn't wise due to security issues.. Mar 24 15:04:08 https://en.opensuse.org/openSUSE:Build_Service_Signer Mar 24 15:04:28 it's much better (security practice) to build the packages (verify the contents / QA) and then sign them as part of your release process Mar 24 15:04:34 that's what I was pointed to by dl9pf while researching Mar 24 15:05:11 YPTM: Brendan joined Mar 24 15:05:32 note the version of RPM that SuSe use is RPM4. RPM4 does not do auto-self signed packages for validation.. Mar 24 15:05:44 YPTM: AlexG on the call Mar 24 15:05:56 YPTM: Paul Eggleton joined Mar 24 15:06:04 bluelightning: Hi Paul Mar 24 15:06:19 RPM5 did this since it can verify the signature -before- processing any package metadata in an attempt to stop (intentionally) corrupt data from causing vulnerabilities.. obviously, an attacker can also self-sign.. but they'd need to know to do it and how to do it properly Mar 24 15:06:41 ...which would change hashes, and other mechanisms people already use for validatiosn that would be difficult (not impossible) to fake.. Mar 24 15:06:52 but a proper signature is the only way to do it "right".. Mar 24 15:07:42 bluelightning: hi paul. how's elc? Mar 24 15:07:48 as for teh SuSE link, the setup chunks for creating the signature look to be valid.. but the actual signing steps are a big different.. Mar 24 15:08:03 in RPM5 you have the ability to either add a signature or replace an existing.. (generally adding is better IMHO) Mar 24 15:08:18 I'm not sure, but I don't believe OBS's signing can 'add', only replace Mar 24 15:09:18 rburton: great so far, lots of people to talk to Mar 24 15:09:40 bluelightning: i hope sean is telling everyone how great i am, i told him to Mar 24 15:10:35 rburton: I haven't heard him saying anything yet, but I'll let you know ;) Mar 24 15:11:15 in RPM5.. you'd use the '--addsign' to add a signature.. and -resign to replace the existing.. Mar 24 15:13:35 bbl Mar 24 16:26:04 * [Sno] waves Mar 24 16:26:36 <[Sno]> someone around can answer some (maybe dumb) questions regarding PACKAGECONFIG? Mar 24 16:28:25 <[Sno]> 1) Is it possible to define PACKAGECONFIG (or add/remove) per recipe (eg. add libvirt only to collectd) Mar 24 16:28:50 <[Sno]> 2) is it possible to define dependencies for a recipe based on it's PACKAGECONFIG? Mar 24 16:30:43 the syntax in a recipe is: packageconfig[foo] = "—enable-argument,—disable-argument,list of build time dependencies,list of runtime dependencies" Mar 24 16:30:48 so that should answer 2) for you Mar 24 16:31:03 <[Sno]> kergoth: thanks, it does ;) Mar 24 16:31:26 and 1) is yes, because it's just a variable in a recipe, and you can override or append to any recipe variable from a config file with overrides Mar 24 16:31:36 PACKAGECONFIG_append_pn-busybox = " foo" Mar 24 16:31:37 for example Mar 24 16:31:43 <[Sno]> cool, thanks Mar 24 16:31:45 or PACKAGECONFIG_remove_pn-nano = "bar" Mar 24 16:31:54 or just PACKAGECONFIG_pn-foo = "a b c" Mar 24 16:32:09 <[Sno]> and maybe the i-dot ... Mar 24 16:32:09 see the docs on OVERRIDES for details on that, the pn-${PN} override is just one of many available Mar 24 16:32:11 just remember if you change the setting you are essentially changing the package's configuration, which changes the checksum, which will cause anything dependning on that package to all change.. (each changed item triggers a rebuild) Mar 24 16:32:26 indeed, good to point that out Mar 24 16:32:38 this doesn't matter to most people.. but you need to be cautious with these changes if you intend to support on-target upgrades via packages Mar 24 16:33:05 <[Sno]> fray: thanks for mentioning, but we deploy only squashfs images ... Mar 24 16:33:06 PACKAGECONFIG settings should be viewed as a system-wide change, that happens to just affect one particular recipe.. Mar 24 16:33:08 yeah, we don't encode that configuration into the binary package metadata in any way, and also we don't support configuration specific build time dependencies either Mar 24 16:33:26 less for you to worry about then Mar 24 16:33:52 <[Sno]> I've seen in collectd_%.bb (http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/collectd/collectd_5.4.1.bb) the python dep is sucked in via "inherit" - this is not dynamic, isn't it? Mar 24 16:34:27 it is not Mar 24 16:34:44 <[Sno]> I know it's system-wide - I just want to ensure that new PACKAGECONFIG for e.g. collectd won't affect more packages than needed (by adding features to them) Mar 24 16:34:48 just because the -build- dependency is there, doesn't mean you need to deploy with it Mar 24 16:35:12 it will cause anything requiring collectd to rebuild.. which could introduce changes (based on libraries, configure discovery, etc..) Mar 24 16:35:31 in this case, significantly less likely to actually trigger a change Mar 24 16:35:32 <[Sno]> that's true - I have to analyze how the result looks like (python-wise ...) Mar 24 16:35:43 more likely in a change to python, perl or other large re-used components Mar 24 16:36:04 <[Sno]> I'd like to add perl support to collectd and libstatgrab ... Mar 24 16:36:58 <[Sno]> well - I'd like to add perl and libstatgrab support to collectd ;) Mar 24 16:44:36 should be possible to do with PACKAGECONFIG settings.. (if it's not "obvious", then it will take recipe specific changes.. but that is what the interface was designed to allow) Mar 24 16:44:52 anything that uses configure to control this is "easy".. anything that doesn't is much harder (but possible) Mar 24 16:50:48 <[Sno]> yeah, the append-file isn't that difficult - but I have serious problems finding the right package-dependent settings from time to time ... Mar 24 16:52:17 thx fray Mar 24 17:01:45 i'm sorry if this is a stupid question, i'm trying to figure out how yocto works. Where do i look to make sure that gcc and build tools get installed with a build? Mar 24 17:03:36 I'm using yocto for the intel galileo board, and it's pretty confusing where everything is Mar 24 17:04:58 you want an image with a toolchain in? add 'tools-sdk' to the IMAGE_FEATURES variable in your local.conf Mar 24 17:05:49 (BTW I don't suggest building ON a galileo.. it's like stepping back in time to the i586 days.. you can go do something else when doing a complicated build...) Mar 24 17:05:55 cross compiling is MUCH faster there.. Mar 24 17:06:08 fray: or compiling in a galileo chroot :) x86 compat is fun Mar 24 17:06:29 you can do that, but I still caution against it.. Mar 24 17:06:42 containers seem to work reliably, but I've hit cases where chroots do unexpected things.. Mar 24 17:07:32 also when using either chroot or containers.. any programs that attempt to identify the host type may discover a CPU that has optimizations that the galileo does not.. causing you to build less then optimized, or code that simply won't execute on the intended target.. Mar 24 17:07:32 weird, i had the opposite :) tried to move to docker from schroot and ended up giving up due to weird issues Mar 24 17:07:36 cross compilation resolves that Mar 24 17:08:09 chroot you are still in the hosts environment.. but may not have access to proc and other things.. (or may be able to 'leak' out..) and it requires "root" Mar 24 17:08:28 containers you can continue to build as non-root.. and have access to a contained proc and device filesystem as appropriate for whatever you are doing Mar 24 17:08:49 yes totally right about leaking, oe toolchain is very nice tbh Mar 24 17:09:14 cross compile == building a .bb file? or is there a direct way to compile stuff? Mar 24 17:11:51 cross compiler, if you are building a single application.. use an SDK toolchain Mar 24 17:12:09 this allows you to manually compile, on a fast host targeting another (usually slower) target system Mar 24 17:12:31 i'm building gphoto2 which needs quite a few libraries... not sure how to do that Mar 24 17:12:55 so for galileo, i build the toolchain with bitbake? Mar 24 17:13:23 build you intended target filesystem.. (try to get all of the libraries for YP, OE, etc you can..) put them into your filesystem... Mar 24 17:13:34 then construct an SDK.. bitbake -c populate_sdk Mar 24 17:13:57 you will get a cross compiler set along with a sysroot that matches your running target image... install the SDK and then you can use that to control your builds.. Mar 24 17:14:24 you source the environment file, and then use a series of environment values to actually build.. If it's configure, there is a helper for that.. if it's simply 'make' you can do that directly.. Mar 24 17:14:32 so for this, i download all the source, and build the libraries needed with the sdk? Mar 24 17:14:58 use the YP to build the SDK.. then you can build in a traditional approach, on your host with the SDK.. Mar 24 17:15:03 i have to set some --prefix values to install the libs in the correct locations Mar 24 17:15:21 what does YP stand for? Mar 24 17:15:22 once you've resolved all of the building issues, I'd encrouage you to package this into recipes and share.. but thats not required Mar 24 17:15:26 Yocto Project Mar 24 17:15:48 use the YP build environenment to build the SDK is what I've referring to Mar 24 17:15:54 ok Mar 24 17:16:08 i built the sdk already Mar 24 17:16:16 ok.. install it, source the environment files.. Mar 24 17:16:24 look at the content of the evnrionemnt files to see what you have.. Mar 24 17:16:35 there is some documentation in progress on the parameters, but I don't know if it was completed.. Mar 24 17:16:41 came out as iot-devkit-eglibc-x86_64-image-full-i586-toolchain-1.6.1.sh Mar 24 17:17:25 yes, run that.. and install it Mar 24 17:17:34 ok, doing that now Mar 24 17:17:47 that will contain your cross compiler (toolchain), sysroot and corresponding items Mar 24 17:18:37 can you point me at a doc that explains how to use the cross compiler. I've never used one Mar 24 17:19:00 it works just like the regular compiler, but you need to setup your environment to make it easier.. Mar 24 17:19:42 ok, so just create a dir for all my libs and applicatons. then source that and build as i normally would? Mar 24 17:20:46 I'm looking for the docs that were in progress Mar 24 17:24:38 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7133 Mar 24 17:24:39 Bug 7133: enhancement, Medium+, 1.8 M3, scott.m.rifenbark, RESOLVED FIXED, Document environment file usage Mar 24 17:25:07 see the comments in that bug, there are references to the YP 1.8 documentation.. it should be very similar to 1.6.1 that you are using Mar 24 17:25:14 ok Mar 24 17:31:07 I would like to put an rpm that is created by yocto into another rpm that is created by yocto, is there an easy way to reference to another package name within a recipe? Mar 24 17:37:35 where should i build the libraries that the other applications need? should it go into /opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/? Mar 24 17:37:50 s/biuld/install Mar 24 17:40:24 you would build them "wherever", but yes.. once built.. you need to copy the headers and libraries into a sysroot. You can certainly copy them into the one that is part of the SDK Mar 24 17:40:42 just be careful you don't overwrite anything you don't intend to overwrite Mar 24 17:41:36 it's just behaving strangely when i tried that ./libtool: line 1107: i586-poky-linux-ranlib: command not found Mar 24 17:43:25 and setting my LD_LIBRARY_PATH to the location i installed the other libs isnt working.... i think i'm just going to turn off my computer and try again tomorrow. Mar 24 17:43:44 then you did not source the environment Mar 24 17:43:56 i did source the env Mar 24 17:44:06 echo $PATH Mar 24 17:44:29 check that something providing i586-poky-linux-ranlib is properly in your path Mar 24 17:44:31 opt/iot-devkit/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/iot-devkit/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/opt/iot-devkit/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/iot-devkit/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/yocto_build/meta-clanton_v1.1.0-dirty/repo-ext/poky/scripts:/yocto_build/meta-clanton_v1.1.0-dirty/repo-ext/poky/bitbake/bin:/yocto_build/meta-clanton_v1.1.0-dirty/scripts:/yocto_bu Mar 24 17:44:31 ild/meta-clanton_v1.1.0-dirty/bitbake/bin:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin Mar 24 17:44:41 i missed the first / Mar 24 17:45:05 Look at /opt/iot-devkit/1.6.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux Mar 24 17:45:08 what do you see there? Mar 24 17:45:47 you want me to copy and paste? Mar 24 17:45:49 that path also looks like you have multiple SDKs or projects loaded at the same time Mar 24 17:45:53 use pastebin.. Mar 24 17:46:36 i586-poky-linux-addr2line i586-poky-linux-cpp i586-poky-linux-gcc-ar i586-poky-linux-gdb i586-poky-linux-nm i586-poky-linux-readelf Mar 24 17:46:36 i586-poky-linux-ar i586-poky-linux-elfedit i586-poky-linux-gcc-nm i586-poky-linux-gprof i586-poky-linux-objcopy i586-poky-linux-size Mar 24 17:46:36 i586-poky-linux-as i586-poky-linux-g++ i586-poky-linux-gcc-ranlib i586-poky-linux-ld i586-poky-linux-objdump i586-poky-linux-strings Mar 24 17:46:36 i586-poky-linux-c++filt i586-poky-linux-gcc i586-poky-linux-gcov i586-poky-linux-ld.bfd i586-poky-linux-ranlib i586-poky-linux-strip Mar 24 17:46:39 dang it Mar 24 17:46:41 sorry Mar 24 17:46:58 :) well the file being requested appears to be there.. Mar 24 17:47:16 i'll close the terminal and start fresh Mar 24 17:47:19 so it's most likely something with your overall system environment, or something specific to that one package Mar 24 17:47:50 one thing I've seen is some people have errant .bashrc's that hard code their PATH =.. so whens omethign starts a subshell it wipes out the inherited environment's PATH Mar 24 17:48:46 i'll look Mar 24 17:49:16 path includes current path and an append Mar 24 17:53:26 still fails Mar 24 17:53:41 "which i586-poky-linux-ranlib" should report the full path Mar 24 17:53:58 if it does, try to run it via that path.. if you get the same error.. then your SDK has a problem with how it was constructed Mar 24 17:54:23 whcih resolves to the path, and then running it directly works Mar 24 17:54:26 there are a couple of confusing messages when the dynamic loader fails... Mar 24 17:54:43 ok.. then it's libtool.. or the thing trying to call libtool.. you'll have to trace it and figure out where it's going wrong Mar 24 17:55:28 and down the rabbit hole i go Mar 24 17:56:04 it works fine if i use a different dest Mar 24 17:56:13 er... a different --prefix= Mar 24 17:57:24 Usually I just define a local path for my builds and installs.. and just set hte --prefix= (and other arguments) there.. Mar 24 17:57:57 even better if you can use the default paths (see the environmetn files configure arguments).. and when you do the 'make install' redirect it to an alternative install location.. Mar 24 17:58:13 the problemw ith passing different --prefix= values to configure is many programs will end up embedded that into it Mar 24 17:58:20 that's what i did first. but then building one of the packages got angry that it couldnt find the libraries Mar 24 17:59:14 it may take an hour to compile on the galileo... but at least it works lol Mar 24 18:28:03 sigh, hitting sstate reuse problems again Mar 24 18:56:19 man, i'm banging my head against a wall on this one. "libgphoto2 requires libltdl (the libtool dl* library)," i have the libs in /opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/lib and the headers in /opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/include Mar 24 18:56:58 all the other dependencies were able to configure and compile. but this one.. Mar 24 18:58:01 re-run libtoolize, perhaps? Mar 24 18:58:04 * kergoth shrugs Mar 24 18:59:15 anything special to do? or just run it in my src/libgphoto2 dir? Mar 24 19:02:26 this cross compile is driving me nuts Mar 24 19:12:57 a common affliction Mar 24 19:12:58 hi guys, I submiteed an OpenCV patch for dylan 09 March 2015 - will it be integrated? Mar 24 19:13:46 [oe] [meta-oe][dylan][PATCH] opencv: Update SRC_URI to use git Mar 24 19:59:57 any idea why running bitbake image-full for the second time doesn't build the bzImage? Mar 24 20:30:10 One of my custom recipes for a library is having trouble during do_rootfs Mar 24 20:31:25 I see the following errors: "error: Can't install [recipe-name]@[arch]: no package provides [library, runtime dependency].so()(64bit)" Mar 24 20:33:00 The runtime dependency is being built, but I suspect may not be getting packaged. What's the best way to check and troubleshoot that? Mar 24 20:55:43 anyone know how to change the size it creates for the ext3 filesystem? Mar 24 21:06:51 cgkates: I think setting IMAGE_ROOTFS_EXTRA_SPACE = "size" in local.conf will do it Mar 24 21:08:11 i'll try that, thanks! is there a doc page that has all those extra settings? Mar 24 21:10:20 Not that I know of... The default rootfs size on my end is 65536, so try going larger than that. Mar 24 21:12:09 it's only allowing for like 50M of free space as it is.. so i can't install anything Mar 24 21:18:40 looks like it might be in here http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html Mar 24 21:19:27 specifically http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE **** ENDING LOGGING AT Wed Mar 25 02:59:58 2015