**** BEGIN LOGGING AT Sun Jan 25 02:59:59 2015 Jan 25 03:33:19 anyone with meta-sourcery experience? getting the following error - variable libc_baselibs references itself! **** BEGIN LOGGING AT Sun Jan 25 03:37:33 2015 Jan 25 16:35:14 bluelightning: is it possible to clean sstate-cache at a machine level? I want to keep native packages but clean all packages related to my target hardware Jan 25 16:42:38 kergoth: hi the latest meta-sourcery (master branch) seems to be broken - any ideas? Jan 25 16:47:48 i use it all day every day Jan 25 16:48:10 stop setting TCMODE, you're setting it incorrectly Jan 25 18:20:30 sometimes when I override a task (e.g do_configure), it doesn't work until I explicitly do "cd ${S}" as the first command. But this is not true always - what's going on? Jan 25 18:47:42 bluelightning: with dizzy, a lot of my autotools based packages have started to break :) Here's an example error output: Jan 25 18:47:51 bluelightning: automake: error: no 'Makefile.am' found for any configure output | autoreconf: automake failed with exit status: 1 | ERROR: autoreconf execution failed. Jan 25 18:49:15 darkhorse_: have you read the migration guide? Jan 25 18:49:48 http://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#moving-to-the-yocto-project-1.7-release Jan 25 18:50:18 bluelightning: no. i wasn't aware of it. thanks - i am going to take a look now Jan 25 18:51:19 bluelightning: earlier, i asked if I can clean sstate for a specific machine.(without deleting sstate cache for native packages). is that possible? Jan 25 18:51:46 no, there's no option for that Jan 25 19:18:17 Hi there Jan 25 20:01:40 hi otavio Jan 25 20:06:26 :) Jan 25 20:13:22 OE is a nice way to heat the ambient ;-) Jan 25 20:13:23 18:13:04 up 20 days, 8:59, 8 users, load average: 24.62, 22.81, 20.74 Jan 25 20:13:25 :P Jan 25 20:14:01 it is indeed Jan 25 20:14:21 firefox too :-/ Jan 25 20:14:30 'yocto - the best tool for turining your hardware into a space heater! Jan 25 20:14:33 ' ;D Jan 25 20:15:05 maybe im being unfair, i should probably blame flash plugin Jan 25 20:15:25 hehe Jan 25 20:15:56 A 6 core machine is useless when 4 images is cooked in parallel :P Jan 25 20:16:25 I'd love for OE to track outputs, besides just inputs, if possible. that would save a lot of rebuilds .. Jan 25 20:17:04 being a total newb to yocto my feeling is there's a lot going on that's not really necessary to give you what you want Jan 25 20:17:35 kroon: yes but the complexity and the processing needed to perform this, maybe this ends not being worth it Jan 25 20:18:19 just looking at the number, 19 GB of crap to produce 69 MB rootfs.tar.bz2 Jan 25 20:18:38 dRbiG: it is not that simple Jan 25 20:19:10 dRbiG: there are real good reasons why OE does things in that way. The most important one is reproducibility Jan 25 20:19:24 otavio: i know, but it still makes me scratch my head when i look at the numbers Jan 25 20:19:54 i also think that this approach makes sense for what the intended workflow/use case is Jan 25 20:20:39 and my recent case of building an image for i586 on x86_64 probably didn't fit it at all Jan 25 20:21:45 ...still the space heating part is true, and the numbers are true :D Jan 25 20:22:29 i even made notes: http://ix.io/fYk Jan 25 20:23:32 dRbiG, you can always enable "rm_work" ;) Jan 25 20:26:21 my feeling (not technical opinion) is that yocto builds an equaly complex layer of its own on top of the complex layer of cross-building a linux distro from scratch Jan 25 20:27:47 e.g. approaching it is rather unpleasent; though i wonder if it might make more sense for someone that has never build a linux from scrtach Jan 25 20:44:03 its 1) crosscompilation and 2) host independence that adds the majority of the complexity. the rest is the nature of having a general purpose distribution building tool which works for any arbitrary target distro and machine Jan 25 21:40:16 kergoth: any ideas why: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=ea647a5f04307a374be5ab19e5defdece40ebdd5 would happen? Jan 25 23:23:59 bluelightning: hi again, i have a custom openssl implementation that provides libcrypto and libssl. but so does the standard openssl. I have setup PREFERRED_PROVIDER_libcrypto = "my-openssl" and PREFERRED_PROVIDER_libssl = "my-openssl" but the system still thinks there are two providers Jan 25 23:24:13 bluelightning: any hints, please? Jan 25 23:33:49 darkhorse_: those are runtime targets I think you'll find - you need to be specifying the build time target which is probably just "openssl" Jan 25 23:38:53 bluelightning: when I need to include openssl into an image i have to specify libcrypto and libssl packages - it doesn't take just openssl or any custom implementation. so when the image looks for providers it find two! hence i tried to set up PREFERRED_PROVIDERS. Are you saying that I should add openssl itself in the IMAGE_INSTALL as opposed to libssl and libcrypto? Jan 25 23:39:39 darkhorse_: no, in IMAGE_INSTALL you specify runtime targets i.e. packages Jan 25 23:40:38 darkhorse_: but to be honest most of the time you do not need to explicitly install any library like openssl - a package containing an executable that links to a library in another package gets a dependency on that library package automatically Jan 25 23:43:17 bluelightning: i see. but let's say you have multiple providers for a runtime library - how do you specify a PREFERRED_PROVIDER for a runtime library Jan 25 23:43:59 darkhorse_: that doesn't really work atm Jan 25 23:45:15 darkhorse_: but it rarely matters - dependencies stated by the recipe are usually build-time targets first, with runtime dependencies following from those Jan 25 23:48:05 bluelightning: i am not sure i followed the last statement. yes, the run time dependencies follow from build time ones. but then the build system would try to provide the runtime dependencies - that's where it will find multiple providers and hence the problem? Jan 25 23:48:52 darkhorse_: having selected a single build time provider of "openssl", only one should be built, hence only one ends up being available at runtime Jan 26 00:00:44 bluelightning: where do i make the selection for the build time provider for openssl? Jan 26 00:01:20 it needs to be done at the configuration level, so local.conf or better a custom distro config Jan 26 00:58:29 bluelightning: do you ever sleep :) Jan 26 01:03:02 darkhorse_: it has been known :) **** ENDING LOGGING AT Mon Jan 26 02:59:59 2015