**** BEGIN LOGGING AT Mon Dec 07 02:59:57 2009 Dec 07 03:29:03 should libstdc++ be in cross or in staging or both? Dec 07 03:53:47 does anyone have a link/tutorial on creating rs232 serial cables for routers/handhelds? Dec 07 05:17:46 Soopaman: That would probably depend a lot on the router/handheld you are trying to connect to Dec 07 05:21:51 a pantech digital frame and wireless router Dec 07 05:22:34 is there a way to create a generic usb serial and multimeter the pads? Dec 07 05:23:26 what would you multimeter the pads for? Dec 07 05:23:31 what exactly are you trying to do? Dec 07 08:20:18 jo Dec 07 08:30:58 hi esben Dec 07 08:55:53 morning Dec 07 08:58:30 hi, has anyone written own recipes using a git repro? Dec 07 08:59:12 i tried but failed... Dec 07 09:00:39 no shit.. Dec 07 09:00:41 i've written two files Dec 07 09:00:48 tobi_: there are lot of examples in recipes/ Dec 07 09:01:22 yes, i had a look at them... but nevertheless, my recipe does not work :( Dec 07 09:02:59 my bb file: http://pastebin.com/mc45bb65 and the inc file: http://pastebin.com/m77c429d1 Dec 07 09:05:52 and that's what i get http://pastebin.com/m1a8c9b11 Dec 07 09:06:18 what does "fatal: Not a valid object name 1" mean? Dec 07 09:07:08 you need to set SRCREV Dec 07 09:07:16 SRCREV="gitrevision" Dec 07 09:08:25 :) Dec 07 09:10:44 and what does gitrevision stand for... sorry... i'm completely new to this :) Dec 07 09:11:10 commit 6a70394463318162c679699bf0d88344e1783dfb Dec 07 09:11:28 that is example of 'git log' - 6a70394463318162c679699bf0d88344e1783dfb is revision 'number' Dec 07 09:12:07 moin Dec 07 09:12:34 aloha zecke Dec 07 09:13:12 thanks! :) Dec 07 09:13:27 i'm trying to get familiar with oe, git and co. :D Dec 07 09:17:57 okay, now it fetchs :) but why does it try things like: NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/git_www.gitorious.org.dam.test.git_d3b7690d84db245a1961294b23d94bdf8cb3372d.tar.gz Dec 07 09:18:22 and does not directly use the url i specify in the bb file? :s Dec 07 09:19:57 zecke: good morning Dec 07 09:22:27 tobi_: because we are upstream friendly and try to cache chckouts Dec 07 09:23:02 okay ;) so i don't have to bother? or can i avoid this? Dec 07 09:23:21 dont bother Dec 07 09:23:25 okay :) Dec 07 10:03:06 good morning Dec 07 10:03:34 hi Marco Dec 07 10:03:48 hello Marcin Dec 07 10:36:57 mickey|office: good morning Dec 07 10:43:33 can someone remind me why we do not have tmp/staging/all-linux dir? Dec 07 10:44:17 morning pb Dec 07 10:44:17 hi hrw Dec 07 10:44:21 hi Dec 07 10:44:35 practically speaking, because nothing gets built with HOST_SYS set to "all-linux". Dec 07 10:45:24 and, I suspect, because we have historically had relatively few PACKAGE_ARCH=all packages which need to stage anything. Dec 07 10:46:37 I'm so happy, meta-toolchain-qte built and worked flawlessly Dec 07 10:47:22 pb_: and now we have Java support in OE which is arch=all Dec 07 10:47:29 indeed Dec 07 10:47:52 in current build I just disabled arch=all for java stuff to get it built Dec 07 10:48:02 I think it would be reasonable for java to stage itself into some generic place, though it's worth bearing in mind that the majority of java classes are not even linux specific. Dec 07 10:49:30 zecke: congratulations# Dec 07 10:49:50 pb_: well, not to me in this case. Dec 07 10:50:01 ah Dec 07 10:50:09 oh well, congratulations to whoever was responsible Dec 07 10:52:52 good morning Dec 07 10:52:56 florian: good morning! Dec 07 12:26:46 Could someone give a hand with shlibs problem? Dec 07 12:27:06 We have a package that is depending on a wrong package Dec 07 12:27:23 instead of it depends on libchicken4 it depends on libchicken Dec 07 12:27:30 but the generated package is libchicken4 Dec 07 12:30:50 Any idea where the problem might be? Dec 07 13:33:44 Humm; I fail to understand where it renames the package name it depends to the debian lib name Dec 07 13:35:56 03Sebastian Spaeth 07org.openembedded.dev * r051bfdfe43 10openembedded.git/conf/distro/shr.conf: Dec 07 13:35:56 shr.conf: Make tux boot splash the default for -unstable (as it effectively already is) Dec 07 13:35:56 Signed-off-by: Sebastian Spaeth Dec 07 13:50:20 03Sebastian Spaeth 07org.openembedded.dev * r566a0285b2 10openembedded.git/recipes/shr/ (shr-splash-theme.inc shr-splash_git.bb): Dec 07 13:50:20 shr-splash,shr-splash-theme: Make PREFERRED_PROVIDER work by tweaking R|PROVIDES and DEPENDS Dec 07 13:50:20 Signed-off-by: Sebastian Spaeth Dec 07 13:54:26 03Sebastian Spaeth 07org.openembedded.dev * r257bfd5d8e 10openembedded.git/recipes/shr/ (shr-splash-theme-logo_git.bb shr-splash_git.bb): Dec 07 13:54:26 shr-splash,shr-splash-theme-logo: Bump PR Dec 07 13:54:26 Signed-off-by: Sebastian Spaeth Dec 07 14:25:41 otavio: see runtime_mapping_rename() in package.bbclass Dec 07 14:40:25 kergoth: good morning Dec 07 14:40:30 hey Dec 07 14:40:40 yo Dec 07 14:56:15 03Steffen Sledz 07org.openembedded.dev * r03aaf9bd90 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig: Dec 07 14:56:15 linux-2.6.24: enable vfat in kernel for hipox machine Dec 07 14:56:15 Signed-off-by: Steffen Sledz Dec 07 15:23:20 XorA|gone, thanks. I saw your comment on the site. Dec 07 15:23:28 i'm working on a new version with fixes. Dec 07 15:23:32 i'll let you know when it's ready. Dec 07 15:29:51 morning all Dec 07 15:39:33 good morning RP Dec 07 15:39:44 03Sebastian Spaeth 07org.openembedded.dev * rb721db910a 10openembedded.git/recipes/shr/shr-splash-theme.inc: Dec 07 15:39:44 shr-splash-theme.inc: add missing _ back to RPROVIDES Dec 07 15:39:44 Signed-off-by: Sebastian Spaeth Dec 07 15:44:14 hi rp Dec 07 15:45:57 how i can i call bitbake to return me all system images available? Dec 07 15:50:19 bitbake -s | grep \\-image? ;) Dec 07 15:54:11 03Philip Balister 07org.openembedded.dev * rbc563bccb0 10openembedded.git/recipes/icu/ (icu-3.6.inc icu-native_3.6.bb icu_3.6.bb): icu : Convert recipe to use INC_PR. Dec 07 16:02:12 hi all. I have a package that RDEPENDS on libpng, but that is not installed... Dec 07 16:02:34 is it because the actual package name is libpng3 due to the debianized name then? Dec 07 16:02:40 this is weird. Dec 07 16:03:53 thx kergoth i will try that Dec 07 16:08:18 i guess i want to know all recipes that will produce a system image Dec 07 16:08:37 if a recipe ends in 'image' but does not do that...it will also be returned from that command I think.. Dec 07 16:08:43 sorry, meeting. bbiab. Dec 07 16:10:09 kgilmer: not sure what you mean by "system image". as far as i know, the only recipe that does anything else is initramfs-image. Dec 07 16:13:42 kergoth, maybe he meant the recipes in recipes/images ? Dec 07 16:22:07 kergoth: heh, that would give you libsdl-image and opie-taskbar-images :-} Dec 07 16:22:18 heh :) Dec 07 16:22:25 would be nice to get a list of recipes that inherit image Dec 07 16:22:31 * kergoth has gotten that request from mv folk too Dec 07 16:22:31 yeah Dec 07 16:23:20 it's a discovery thing. what's available, what can i build.. what distros can i use, what machines do we support, etc.. would be nice to make all of that available without them having to ls & grep :) Dec 07 16:23:36 right. I suspect that's what kgilmer is trying to accomplish as well. Dec 07 16:29:51 arg, due to differences in classes and the like, i can't use both oe and mvl6 in a single project anymore without parse errors in one or the other or both... time to try to sync back up and reduce deviations, i guess.. Dec 07 16:31:18 kergoth, for machine<->distro there is a wiki page but it's highly incomplete Dec 07 16:31:31 it's a wiki, what else is new :) Dec 07 16:32:31 http://wiki.openembedded.net/index.php/Overview_of_OE_supported_machines Dec 07 16:33:23 this is nightmare page Dec 07 16:36:16 * florian agrees Dec 07 16:36:46 it is good to have information about machines in there but filling this table is a nightmare. Dec 07 16:37:13 hrw, what don't you like about it? Dec 07 16:37:39 so what should we do? generate it automatically? Dec 07 16:37:40 it might be better tp parse the machines and generate one. the dictro compatibility is not really useful anyway Dec 07 16:37:49 Crofton|work: it ends far beyond my browser window, do not list usable stuff Dec 07 16:38:40 btw I've some man in /usr/man/zh_TW/man6/wesnothd.6 Dec 07 16:39:08 the build system is cmake...I'll look if there is a flag to move that Dec 07 16:40:04 the features we could link to, and include only a very brief summary field and use the rest of the space to record OE status? Dec 07 16:40:36 GNUtoo: that doesn't look like its properly obeying our paths.. /usr/man isn't our default mandir, iirc Dec 07 16:40:48 I know Dec 07 16:40:59 ah, right :) Dec 07 16:40:59 but the other paths seem ok Dec 07 16:42:13 for instance wesnoth-data/usr/share/wesnoth/sounds/bell.wav Dec 07 16:42:17 I'll try to fix it Dec 07 16:44:46 mmm Dec 07 16:44:47 it' Dec 07 16:45:05 s the same problem discussed yesterday with woglinde Dec 07 16:45:21 MANDIR:STRING=man -> MANDIR:STRING=share/man Dec 07 16:45:29 so mandir - prefix Dec 07 16:45:38 so python function Dec 07 16:46:30 is it a problem if no man are shiped? Dec 07 16:47:05 not an enormous problem. if it's hard to get them in the right place then, pragmatically, I would just not ship them at all. Dec 07 16:47:59 I have never actually heard of anybody installing the manpages on a target device. I guess it probably does happen but it is not very widespread, and I doubt too many people would be seriously upset by lack of the wesnoth manpages. Dec 07 16:50:21 GNUtoo: you can always to do_install_append() { mv manpages} Dec 07 16:50:38 ok I'll do that Dec 07 16:50:44 thanks Dec 07 16:51:21 GNUtoo: it would be nice if we could build & package them everywhere, but it's not always practical. many recipes get their documentation builds disabled to reduce the # of build time deps, today Dec 07 16:51:32 ok Dec 07 16:51:53 I'll move the man then I've the 2 icons to move (where?) Dec 07 16:53:07 mmm Dec 07 16:53:46 I hope ${prefix}/man works with all distros Dec 07 16:54:00 GNUtoo: ${mandir} Dec 07 16:54:10 Crofton|work: machine list should also have informations usable for embedded environments. does machine supports gpio, i2c, i2s, adc, dac, rs232/422/485 etc Dec 07 16:54:24 ${mandir} is the target Dec 07 16:54:39 but ${prefix}/man is what to move Dec 07 16:54:48 because mandir is /usr/share/man no /usr/man Dec 07 16:54:54 ah ok :) Dec 07 16:55:04 I'd look at its buildsystem to see what its using for its make install Dec 07 16:56:10 yes but it would require an ugly hack Dec 07 16:56:49 with regex etc... Dec 07 16:57:05 basically remove ${prefix} from ${mandir} Dec 07 16:57:14 because I bet that the .replace could fail Dec 07 17:02:00 Hi. Does bitbake read MACHINE and DISTRO from the environment? Dec 07 17:02:10 mario-goulart, it can Dec 07 17:02:10 I mean, can I run bitbake like Dec 07 17:02:26 MACHINE=my-machine DISTRO=my-distro bitbake my-recipe Dec 07 17:02:30 export MACHINE="foo"; bitbake foo-image should work Dec 07 17:03:27 Crofton|work: thanks. Dec 07 17:05:27 in the ml some people used it Dec 07 17:10:33 so where should ./usr/share/pixmaps/wesnoth-icon.png go? Dec 07 17:10:42 maybe I should grep on the target Dec 07 17:10:47 s/grep/find Dec 07 17:12:30 mmm I'll ship them in the same location Dec 07 17:20:10 pb__: I do not agree :) Dec 07 17:20:57 florian: about the manpages? Dec 07 17:21:10 pb_: about the fonts :-) Dec 07 17:21:14 oh, heh, right Dec 07 17:21:21 yeah, I was just reading your last on that subject Dec 07 17:21:39 just to be clear, when I said "eliminate it for yourself", what I meant was that you should add a line like Dec 07 17:21:41 NEATSTUFF_florianos = "gdk-pixbuf-loader-png gdk-pixbuf-loader-jpg" Dec 07 17:21:43 to gtk+.inc Dec 07 17:22:09 right - that's more or less what I do now Dec 07 17:22:18 but that's not really my point Dec 07 17:22:45 yeah, I think I understand what you are saying Dec 07 17:22:55 the idea of a library that depends on some data pulling in a random provider for this is just broken by design Dec 07 17:23:07 I agree that it is a shame to have all this historical cruft lying around and it would be nice to eliminate it. Dec 07 17:23:31 personally I am not all that wild about having gtk+ recommend the xpm and gif loaders either Dec 07 17:24:00 Its even more a shame because we had a different provider all the time Dec 07 17:24:47 but, given that this bogus recommendation has been in there for ages and some folks have (almost certainly) become accustomed to its existence, I am not sure that the hassle of removing it is justified by the benefits. Dec 07 17:24:47 xes indeed - that should be the distribution dealing with these too... cluttering all recipes with distribution specific changes is not nice too Dec 07 17:27:11 indeed it's not. making a cleaner separation of the packaging details from the compiling details, and consigning all the packaging stuff to some or other distro config file, would be a worthy goal. Dec 07 17:27:15 The actual benefit in terms of flash consumption is limited. The benefit for a cleaner design of OE is much higher Dec 07 17:27:53 right Dec 07 17:27:55 yeah. if the benefit is cleaner design then it would probably be better to deal with that as part of a wider cleanup and/or restructuring of metadata. Dec 07 17:28:17 conceptually, all a recipe should be responsible for is building itself and doing a do_install Dec 07 17:28:41 That's why I mentioned this on the list... a local fix I have. Dec 07 17:28:58 I don't think it is worth fighting a design battle on a package-by-package basis, it would be better to come up with a general solution. Dec 07 17:29:01 kergoth: right, exactly Dec 07 17:30:04 kergoth: hum well... yes mostly. or it should never RDEPEND on something that could be exchanged. Dec 07 17:30:11 mmm in which package is libpng3? when I do bitbake libpng I don't see the package I have only libpng libpng12 libpng12-dev libpng-dbg libpng-dev ....but when I download the control file from libpng3 in shr/merge repos I get OE: libpng Dec 07 17:30:14 pb_: yes indeed... this might be a tough fight. Dec 07 17:30:18 Crofton|work, GNUtoo: I could only get it to work by adding MACHINE and DISTRO to bitbake's envvar whitelist. Is it correct? Dec 07 17:30:47 mario-goulart, mmm I could check the mailing list if you want....for the usage Dec 07 17:31:49 florian: making gtk+ depend on "virtual-core-fonts" or something, which can be provided by the ttf-dejavu-whatever, is probably as good as it is going to get for a short term fix. In the longer term I think we want a more radical solution like eliminating and/or outlawing all references to RRECOMMENDS in .bb files. Dec 07 17:32:04 GNUtoo: are there any special keywords to search for or MACHINE, DISTRO and environment variables should be enough? Dec 07 17:32:15 pb_: right Dec 07 17:32:19 cofee Dec 07 17:32:24 and, of course, inventing some alternative way for the distro to describe how it wants the binary artifacts to get packaged and what their relationships should be. Dec 07 17:32:25 s/cofee/coffee Dec 07 17:32:28 and multiple Dec 07 17:32:31 more power to the distributions! :) Dec 07 17:32:41 indeed. all power to the distributions, in fact. Dec 07 17:33:06 because koen said in the thread something about liking coffee pauses Dec 07 17:33:43 [oe] Ideas for scripts, to save work, when building several boards Dec 07 17:33:51 base-files is a fairly good example of the sort of scar tissue that you currently end up with when different distros have varying ideas about what they want in their packages, it isn't very pretty. Dec 07 17:34:18 GNUtoo: :-) Dec 07 17:34:22 GNUtoo: thanks. :-) Dec 07 17:35:07 pb_: good point... Dec 07 17:35:15 MACHINE=mymachine bitbake foo Dec 07 17:35:20 GNUtoo: I thought you were about to get multiple coffees. :-) Dec 07 17:35:27 lol Dec 07 17:35:54 florian: I guess this would be a good issue to take to our newly inaugurated TSC :-) Dec 07 17:35:59 GNUtoo: that's what I tried, but it works only when I explicitly add MACHINE and DISTRO to bitbake's whitelist. Dec 07 17:36:07 mmm Dec 07 17:36:15 pb_: indeed Dec 07 17:36:18 in the thread there is: Dec 07 17:36:50 * florian needs to run - baby duties this evening, bbiab Dec 07 17:37:02 florian: enjoy Dec 07 17:37:18 Yes, local.conf takes precedence over env, so remove it from local.conf. Dec 07 17:37:25 mario-goulart, ^^^ Dec 07 17:37:40 so remove MACHINE from local.conf and retry Dec 07 17:38:11 else read the thread...because maybe it contain a better solution Dec 07 17:39:22 GNUtoo: hmmm. Weird. I have no settings for MACHINE in any of the conf/ files. Dec 07 17:39:57 mario-goulart, mmm so read the thread and if you don't find something ask here or on the mailing list Dec 07 17:41:48 GNUtoo: right, thanks for your help. I just found the mailing list thread. Dec 07 17:41:57 ok Dec 07 17:45:04 Aditya: are you around? Dec 07 17:45:32 mmm I suspect the debian renaming Dec 07 17:45:49 how do I deal with that? Dec 07 17:45:57 adding libpng3 to RDEPENDS doesn't work Dec 07 17:48:01 NOTE: Runtime target 'libpng3' is unbuildable, removing... Dec 07 17:48:15 there isn't much about rdepends in the manual Dec 07 17:49:26 GNUtoo: what are you trying to achieve? it shouldn't be necessary to manually depend on libpng3 or any such library. Dec 07 17:49:40 pb_, the library is dlopened Dec 07 17:50:24 ah, that is unfortunate Dec 07 17:50:34 libpng is one of the worst possible libraries to pick for dlopening purposes :-} Dec 07 17:51:03 lol Dec 07 17:51:10 so what should I do? Dec 07 17:51:27 I've updated the wesnoth recipe and that was the last step Dec 07 17:51:42 I can't commit a non-working thing Dec 07 17:51:59 s/can't/wont't Dec 07 17:52:30 personally I would go and cry in the corner. if that's not an option for you then the lowest-impact solution is probably to add some code to your .bb file to figure out what libpng has gotten renamed to and splice it into RDEPENDS just before packaging. Dec 07 17:53:16 if wesnoth has a particular libpng SONAME hardwired into it then it's going to be inherently fragile, I don't think there is any very elegant way of solving that problem. Dec 07 17:53:36 mmm....and what if I modify libpng recipe Dec 07 17:53:37 ? Dec 07 17:53:44 a lower-tech alternative which would probably work would be to add a PACKAGES_DYNAMIC kind of thing to libpng. Dec 07 17:53:47 like FILES_${PN}3 = Dec 07 17:53:48 03Khem Raj 07org.openembedded.dev * r0d0a49c2b6 10openembedded.git/recipes/uclibc/ (3 files in 2 dirs): Dec 07 17:53:48 uclibc-nptl: Update to lastest git rev. Dec 07 17:53:48 * Add patch to fix build issue in rpc. Dec 07 17:53:48 * Apply installfix patch to sort out parallel builds. Dec 07 17:53:48 Signed-off-by: Khem Raj Dec 07 17:54:58 I don't quite understand what you are trying to do with FILES_*. I don't think changing those variables will help but I might be missing the point you are making. Dec 07 17:55:19 mmm Dec 07 17:55:45 Basically, you have two underlying problems: firstly, the soname of libpng is somewhat unpredictable, which makes it hard to know (a) what filename you should pass to dlopen(), and (b) what package you would find that file in; Dec 07 17:56:09 ouch Dec 07 17:56:19 secondly, in the presence of library renaming, there is no convenient way to express a manual dependency on a package that has been renamed. Dec 07 17:56:27 indeed Dec 07 17:56:52 what is PACKAGES_DYNAMIC,the manual says : This section is to be completed. Dec 07 17:57:34 it's basically a workaround for bitbake's inability to do proper introspection on packages: it is sort of a forwards declaration of the binary packages that will come out of this build. Dec 07 17:57:38 GNUtoo: informs bitbake about packages emitted dynamically, via things like do_split_packages Dec 07 17:57:50 ok Dec 07 17:58:04 hmm, OT, but anyone know how git-log distinguishes the options that go to diff-tree vs rev-list, or if its manual? Dec 07 17:58:05 it's primarily there to cope with runtime package splitting, but in practice it is a sort of PROVIDES-equivalent for the runtime space. Dec 07 17:58:26 mmm I could install all libpngs? Dec 07 17:58:39 that would be ugly but it could work no? Dec 07 18:00:00 else how do I use PACKAGES_DYNAMIC ? Dec 07 18:00:07 * XorA is puzzled how kexecboot finds its initramfds Dec 07 18:00:39 GNUtoo: what? PACKAGES_DYNAMIC tells bitbake about binary packages a recipe will//can emit, that's all Dec 07 18:01:29 in theory you could install all libpngs by having them all Provide: virtual-libpng and arranging for wesnoth to Depend: on virtual-libpng* (with the asterisk). but, I gather that this function is currently broken in opkg, so it might not help you too much. Dec 07 18:01:41 I guess you probably don't want to get into debugging opkg as a precursor to solving your problem :-) Dec 07 18:01:45 ouch Dec 07 18:01:57 pb_: greedy depends should still work Dec 07 18:02:03 pb_: OE just doesnt use them Dec 07 18:02:12 ah, some guy told me that they were broken. Dec 07 18:02:19 they worked last I tested Dec 07 18:02:35 oh, very good. Dec 07 18:03:02 GNUtoo: tried RDEPENDS += "libpng" and check will it resolved by debian mangling? Dec 07 18:03:14 hrw, I'll try now Dec 07 18:09:35 mmm....I'll wait for it to build,install and look at the result,thanks a lot!!! for all the help Dec 07 19:05:24 wow Dec 07 19:05:26 Depends: wesnoth-data, libpng3,... Dec 07 19:05:30 thanks a lot hrw Dec 07 19:05:37 I'll try it on real target now Dec 07 19:05:42 and commit Dec 07 19:05:53 btw if someone want to add something for large screen feel free Dec 07 19:06:44 (it also works on large screen but there are some issues that could be avoided on large screen without the small cmake screen configure option) Dec 07 19:06:54 s/small cmake/cmake small Dec 07 19:22:48 mario-goulart, I should have mentioned the whitelest, you are doingthe right thing Dec 07 19:29:12 Crofton|work: thanks. I'm doing BB_ENV_EXTRAWHITE='MACHINE DISTRO' MACHINE='my-machine' bitbake my-recipe Dec 07 19:29:19 Crofton|work: seems to be working fine. Dec 07 19:38:34 florian: wb Dec 07 19:38:45 jo Dec 07 19:38:47 hi pb Dec 07 19:38:52 hi woglinde Dec 07 19:39:12 re Dec 07 19:41:04 hey there woglinde pb_ Dec 07 19:41:32 wb Dec 07 19:43:20 he kglimer Dec 07 19:43:26 hi dth Dec 07 19:48:40 woglinde, hi the recipe is ready...but SSH_AUTH_SOCK="" git push origin org.openembedded.dev => fatal: The remote end hung up unexpectedly Dec 07 19:49:29 I don't know if you were here but I pushed in a dirty way before...maybe because I had this error and found a workarround Dec 07 19:50:25 hm Dec 07 19:52:07 the workarround made it to push to all the branches I was on so I don't want to use it again Dec 07 19:52:44 I'll send my config Dec 07 19:53:16 http://pastebin.com/m54211411 Dec 07 19:55:12 jo zecke Dec 07 19:56:06 what should I do? I've the commit pending... Dec 07 19:56:21 hm Dec 07 19:56:30 dont know Dec 07 19:56:44 maybe you are pushing false? Dec 07 19:56:53 I'll look if I can change origin to the push address Dec 07 19:56:55 I am using Dec 07 19:56:56 git push origin org.openembedded.dev:org.openembedded.dev Dec 07 19:57:09 where org.openembedded.dev is my cloned branch Dec 07 19:58:10 ok Dec 07 19:58:16 I'll try that Dec 07 19:59:52 same error Dec 07 20:00:15 hm Dec 07 20:00:32 maybe otavio knows... Dec 07 20:00:33 maybee ip is wrong Dec 07 20:00:37 ah Dec 07 20:00:41 I'll try to ping Dec 07 20:00:45 in the settings Dec 07 20:00:48 or host Dec 07 20:00:52 oyu can pull? Dec 07 20:00:59 whats git branch -a saying? Dec 07 20:01:15 64 bytes from melo.openembedded.org (140.211.169.165): icmp_seq=1 ttl=43 time=212 ms Dec 07 20:01:41 branch -a says the good branch that is : * org.openembedded.dev Dec 07 20:02:09 and I just pulled before chery-picking Dec 07 20:09:12 mmm what can I do then? Dec 07 20:09:32 should I ask on #git Dec 07 20:09:33 ? Dec 07 20:09:44 else I've got a very bad idea Dec 07 20:10:10 put that as address: git@git.openembedded.org:openembedded Dec 07 20:10:21 aeh? Dec 07 20:10:21 or try with that but specifying a branch Dec 07 20:11:15 hm Dec 07 20:11:17 url = git@git.openembedded.net:openembedded Dec 07 20:11:25 in .git/config Dec 07 20:11:32 fetch = +refs/heads/*:refs/remotes/origin/* Dec 07 20:11:46 [branch "org.openembedded.dev"] remote = origin merge = refs/heads/org.openembedded.dev Dec 07 20:12:53 ok I'll try Dec 07 20:12:55 thanks a lot Dec 07 20:13:06 mom Dec 07 20:13:15 I will paste whole file Dec 07 20:13:22 ok lol Dec 07 20:13:39 http://pastebin.ca/1705974 Dec 07 20:15:58 the origin url seems the cause Dec 07 20:16:01 thanks a lot I'll try Dec 07 20:17:32 03Denis 'Gnutoo' Carikli 07org.openembedded.dev * r579e0bbc02 10openembedded.git/recipes/wesnoth/wesnoth_1.6.5.bb: (log message trimmed) Dec 07 20:17:32 wesnoth: add version 1.6.5 Dec 07 20:17:32 First thanks to: Dec 07 20:17:32 *hrw for telling me how to solve a complicated libpng3 RDEPENDS problem: Dec 07 20:17:32 libpng is,as pb_ explained,is renamed to libpng3 in a way that we can't Dec 07 20:17:34 predict...so the solution was to add libpng3 to RDEPENDS and bitbake Dec 07 20:17:38 would have renamed it automatically,and it did. thanks a lot! Dec 07 20:18:01 thanks a lot Dec 07 20:18:03 lol Dec 07 20:18:07 hehe Dec 07 20:18:14 yes as usual the logs are huge Dec 07 20:18:24 but I use the separation line Dec 07 20:18:33 (it doesn't shows up on irc) Dec 07 20:19:25 meh Dec 07 20:19:32 ko kergoth Dec 07 20:19:36 master Dec 07 20:19:57 * kergoth is trying to resolve issues with class/cfg differences between OE overlays causing parse problems :\ Dec 07 20:25:51 kergoth: doh, what goes wrong? Dec 07 20:25:52 hi kgilmer Dec 07 20:26:53 a variety of issues. infinite loop trying to expand some staging var refs due to changes in those vars & layout_*, some local differences in the kernel classes, that stupid ass python-native check when expanding PYTHON_INCDIR, .. Dec 07 20:28:51 ah, yeah, that layout_* mutual recursion is annoying. I ran into that a few times. Dec 07 20:30:51 makes me wonder how best one could avoid this type of thing. not sure, its ugly.. could move more of the metadata defaults into the classes and version the classes, .. i dunno :) Dec 07 20:46:26 Hi .... Is the correct way to send a patch just to send it, or is it better to talk to you guys first? Dec 07 20:51:01 make sure it is formatted properly Dec 07 20:51:13 look on the webiste for commit message policy Dec 07 20:51:55 Crofton|work: ok. Thanks. Dec 07 21:05:48 Crofton|work: Should'nt it be enough to fire up git send-email --smtp-server and the specify openembedded-devel@lists.openembedded.org and recipient .... ? Dec 07 21:06:32 yes, but make sure the commit message follows what we would like Dec 07 21:07:28 Crofton|work: yes, but apparently the email never arrives ....... I get it to my own address, but the list never gets it. Dec 07 21:10:00 you are subscribed to the list? Dec 07 21:12:04 Crofton|work: yes :p Dec 07 21:13:04 Crofton|work: I'll check the sender in the email sent. git might be using something which the list does not like .. Dec 07 21:13:11 yeah Dec 07 21:18:22 Crofton|work: sorry to bother you with this basic problem, but does it look okay: http://pastebin.ca/1706053 ? Dec 07 21:19:09 yeah, but I am not an expert Dec 07 21:19:13 sgh: RCPT TO is a syntax error Dec 07 21:19:30