**** BEGIN LOGGING AT Tue Mar 22 02:59:57 2011 Mar 22 03:16:43 grg: how is opkg overhaul going Mar 22 03:18:26 khem, i Mar 22 03:18:31 've taken a break this past week Mar 22 03:18:35 grg: Dont know if you follow cricket but its Aus Vs Ind in WC Quarter Final Mar 22 03:18:43 grg: great Mar 22 03:18:44 (damn ' char... i keep hitting return instead) Mar 22 03:18:55 * khem hopes to get a break soon Mar 22 03:19:41 feeling burnt out Mar 22 03:19:44 i think i have most of the low level bits in place, just need to fix write high level code for install/upgrade/remove Mar 22 03:20:04 everyone needs a break occasionally Mar 22 03:21:11 i have ar/tgz handling code working fine. Dependency resolution works. Mar 22 03:21:24 parsing, etc. Mar 22 03:21:41 cool Mar 22 03:22:01 need to autotool it Mar 22 03:22:10 I think it would be a nice alternative in furture oe-core Mar 22 03:22:15 and reorganise the code into a lib Mar 22 03:23:46 * grg has a new toy, so is spending spare time with it, instead of coding... http://www.krisholm.com/khu/kh29 Mar 22 03:29:44 ah unicycle Mar 22 03:29:50 thats impressive Mar 22 03:30:15 it will be far more impressive when i stop falling off Mar 22 03:30:37 I bet its hard to learn that Mar 22 03:30:55 surprisingly, no Mar 22 03:31:03 hmm Mar 22 03:31:13 most people only need a few hours to be able to go forwards reasonably well Mar 22 03:31:23 I see one tied to a light post on way to grocery store all the time Mar 22 03:31:31 e.g. 30mins a day for a week Mar 22 03:31:36 hmm Mar 22 03:31:53 (but learn on a 20" wheel, not the 29" i've just bought) Mar 22 05:38:29 Hi all, I copied omapfb-main driver as omapfb-main-backeup and ran bitbake virtual/kernel, even then i am seeing the print statements i added in omapfb-main in bootlog of new uImage, how is this possible? Mar 22 05:53:17 well I deleted my tmp directory and recompiled everything, that's fixed my C++ compiler not installed issue, though I don't understand what was wrong before Mar 22 05:53:44 NotTooDumb3: I don't really understand your question Mar 22 05:54:43 maybe I'm missing a whole lot of context, like what are these drivers you're copying Mar 22 05:55:11 vadmium, for testing i copied one driver namely drivers/video/omap2/omapfb/omapfb-main.c as drivers/video/omap2/omapfb/omapfb-main-backup.c as I did not want it to get compiled, for testing.. Mar 22 05:55:52 and got uImage with bitbake virtual/kernel still in boot log i am seeing printks i added in omapfb-main.c file Mar 22 05:56:39 vadmium, you deleted your tmp directory meaning you deleted whole of the source code too? Mar 22 05:57:42 if you wanted to remove your printks wouldn't you copy the original file over the top of main.c rather than the other way? Mar 22 05:58:25 my downloaded source code is outside the tmp directory Mar 22 05:59:02 was just following up about a problem I had earlier today, like 6 hours ago Mar 22 05:59:34 what I am trying to do not just remove my printks, but wanted to test omap/omapfb-main.c inplace of omap2/omapfb/omapfb-main.c so on the way of doing that, I just removed omap2fb driver for testing Mar 22 05:59:57 oh..ok Mar 22 06:01:35 I'm not really familiar with these drivers Mar 22 06:01:58 ok. Mar 22 06:02:22 all I can suggest is, bitbake or OE will often ignore changes in the work directory for source code unless you trick it Mar 22 06:02:45 eg if it thinks it needs to unpack the linux kernel I think whatever changes you've made will be gone Mar 22 06:03:06 otoh if you made changes and it thinks it's already build it, then it won't rebuild Mar 22 06:03:32 how can i forcefully make it rebuilt? any idea?? Mar 22 06:04:13 "unless you trick it" meaning? Mar 22 06:05:16 umm not sure on the "official" way if ther eis one, but thinks like deleting the stamp file for say the compile step Mar 22 06:06:02 or you can run bitbake for eg the patch step, then edit the work dir, then run bitbake to finish the job Mar 22 06:06:27 I'm sure I read a bit of this in the manual but I can't find it now Mar 22 06:06:43 ok.. Mar 22 06:10:55 NotTooDumb3: http://docs.openembedded.org/usermanual/usermanual.html#usage_workwithsinglerecipe Mar 22 06:11:17 that might be useful, especially a bit further down: "a typical development session" Mar 22 06:46:11 gm Mar 22 07:27:52 I'm creating a recipe that should just build one c-file. Is there a class I should inherit for this? Mar 22 07:32:02 I have a feeling this should be simple :) Mar 22 07:44:20 good morning Mar 22 07:44:25 tasslehoff: helloworld_1.0.0.bb ? Mar 22 07:52:01 mckoan: yeah. I ended up doing something similar, and realized that my Q wasn't very clever. without a makefile of some sort OE a class would have to be clever to understand what I wanted :) Mar 22 08:03:35 I added vim and vim-syntax to my rootfs. What makes it pick gvim (that I do not want)? Mar 22 08:16:44 tasslehoff: any link? Mar 22 08:18:50 mckoan: pastebin'd bitbake output? Mar 22 08:23:31 NOTE: multiple providers are available for runtime vim-syntax (gvim, vim-tiny, vim) Mar 22 08:23:33 NOTE: consider defining a PREFERRED_PROVIDER entry to match vim-syntax Mar 22 08:23:56 probably explains it, I guess. Mar 22 11:47:19 Hi Mar 22 11:49:53 I am working on a gumstix and I've got some errors with udlfb (the displaylink drivers), when i try to load the kernel module the kernel complains with "unknown symbol vesa_modes" (and google does not really help with that) Mar 22 12:00:02 unknown symbol, isn't that usually when your module depends on another module being loaded first? Mar 22 12:00:17 adraen: ^^^ Mar 22 12:00:47 I do this so too but can't find on which one unfortunately :/ Mar 22 12:00:58 hmm okay' Mar 22 12:01:49 * vadmium isn't a big expert on kernel modules Mar 22 12:03:08 and when google don't give any result its often quite bad :D Mar 22 12:09:02 found the problem don't know how to fix it though, from what it looks like the displaylink kernel module in oe is outdate so it uses some symbol exported by the 2.6.31 kernel Mar 22 12:31:06 when i did build a toolchain images and installed it on new machine .. what are the configure parameters so it uses the headers and libs of the toolchain ? Mar 22 12:39:29 good afternoon Mar 22 15:17:19 Hello Mar 22 15:17:38 I sent a patchset that we're using here at O.S. Systems. Could someone take a look and push those if agree? Mar 22 16:28:50 filled disk, now I get "OperationalError: database is locked". How to fix? I'd hate to have to rebuild everything (again) Mar 22 16:34:46 make a space on disk? Mar 22 16:41:51 :-) Mar 22 16:41:53 heh Mar 22 16:44:43 you can add INHERIT += "rm_work" to your local.conf Mar 22 16:44:52 after freeing up a little bit of space somewhere, that is Mar 22 16:47:43 03Martin Jansa  07master * rba80b0f798 10openembedded.git/ (10 files in 6 dirs): (log message trimmed) Mar 22 16:47:43 e-wm: use ESYSACTIONS,EMENU,ECONFIG,ETHEME variables instead of hardcoded e-wm-sysactions/e-wm-menu runtime dependency Mar 22 16:47:43 * ILLUME_THEME/ILLUME_CONFIG were renamed to ETHEME/ECONFIG to use the Mar 22 16:47:43 same variable names as task-demo-x11/task-beagleboard-* Mar 22 16:47:43 * e-wm-sysactions-shr doesn't need RPROVIDES anymore Mar 22 16:47:43 * fixes last multiple providers notice I had Mar 22 16:47:44 NOTE: multiple providers are available for runtime e-wm-sysactions (e-wm, e-wm-sysactions-shr) Mar 22 16:52:31 03Tom Rini  07master * r4f79b1fea3 10openembedded.git/recipes/coreutils/ (coreutils-native.inc coreutils-native_8.5.bb): Mar 22 16:52:31 coreutils-native: Disable gmp support Mar 22 16:52:31 Without this option it will link vs the host libgmp (or not) Mar 22 16:52:31 depending on what's thre which can lead to cache inconsistencies. Mar 22 16:52:31 Signed-off-by: Tom Rini Mar 22 17:03:42 03Martin Jansa  07master * r4f883343de 10openembedded.git/conf/bitbake.conf: (log message trimmed) Mar 22 17:03:43 bitbake.conf: define shared PERSISTENT_DIR Mar 22 17:03:43 * import from poky 6a11cf7dfe930461a6660e3b783b546fa2634900 Mar 22 17:03:44 * we had CACHE var pointing to machine specific dir since 2006 Mar 22 17:03:44 caf077679022f37ce55d758101f130e4e93bd7b5 Mar 22 17:03:45 * current bitbake is looking for cache dir like this: Mar 22 17:03:45 cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or Mar 22 17:03:53 03Martin Jansa  07master * rc3604894c1 10openembedded.git/classes/native.bbclass: (log message trimmed) Mar 22 17:03:53 native.bbclass: define empty PACKAGES_DYNAMIC Mar 22 17:03:53 * suggested by kergoth on #oe as response to similar patch limited to gtk+ Mar 22 17:03:53 http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-March/031074.html Mar 22 17:03:53 15:03 < kergoth_> JaMa: pretty sure we just need PACKAGES_DYNAMIC = "" Mar 22 17:03:53 and PACKAGES_DYNAMIC_virtclass-native = "" in native.bbclass. Mar 22 17:03:54 everyone i've talked to so far as agreed that it's a sane approach, Mar 22 17:04:47 otavio: I will take a look Mar 22 17:05:08 * khem is getting sick Mar 22 17:06:23 khem: flu? Mar 22 17:06:59 yeay and body pains Mar 22 17:07:15 crap Mar 22 17:07:16 kids brought it Mar 22 17:07:24 your kids? Mar 22 17:07:31 they sufferred for a day and here I am it will take be 2 weeks Mar 22 17:07:38 I envy their immunity Mar 22 17:07:42 yes Mar 22 17:08:58 khem: heh Mar 22 17:09:00 hmm so Anand Chandrasekhar resign from Intel Mar 22 17:09:25 did he quit or was made to quit Mar 22 17:09:41 he is the guy who has been heading atom into mobile phones Mar 22 17:09:47 I think intel is not happy Mar 22 17:10:20 * khem remembers him from times Mar 22 17:17:48 re Mar 22 17:19:29 woglinde: otavio: about the xz/lzma...do we stay with old lzma or move to xz-lzma ? Mar 22 17:20:11 btw in 2.6.38 xz appears in the decompressors list Mar 22 17:20:13 any qmake people around? Mar 22 17:20:21 http://pastebin.com/46BhrDUQ Mar 22 17:21:12 ant_work: I am using .38 with xz and it works. Mar 22 17:21:52 ant_work: what I suggested is to use xz --format=lzma to compress the rootfs Mar 22 17:22:03 ant_work I dont know Mar 22 17:22:04 ant_work: so we don't need to maintain lzma recipe Mar 22 17:22:09 I just hit this error Mar 22 17:22:10 we have lzma-native and xz-native yes? Mar 22 17:22:26 debian has xz-lzma Mar 22 17:22:45 that would be the native dep Mar 22 17:22:46 whats your problem crofton? Mar 22 17:23:57 crofton and were is the .pro file? Mar 22 17:24:10 this is the makefile for a native build Mar 22 17:24:15 ant_work: I see no reason to usa xz-lzma of xz can make lzma Mar 22 17:24:15 but it refers to OE vars Mar 22 17:25:45 so xz-lzma Mar 22 17:25:49 or xz -lzma Mar 22 17:26:12 otavio: is more grained Mar 22 17:26:20 http://packages.debian.org/squeeze/all/xz-lzma/filelist Mar 22 17:26:36 but yes, I'll move kernel + initramfs to xz for 2.6.38 Mar 22 17:26:38 ant_work: for grained you mean? Mar 22 17:26:54 hmmm Mar 22 17:27:02 for package management Mar 22 17:27:18 ant_work: what I suggest is... hold Mar 22 17:27:52 ah source /usr/share/qtopia/environment-setup Mar 22 17:28:14 Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils. Mar 22 17:28:34 transition Mar 22 17:29:14 ant_work: http://paste.debian.net/111627/ Mar 22 17:29:30 qtopia? Mar 22 17:29:36 qtopia is long dead Mar 22 17:29:47 dont raise it from it Mar 22 17:30:45 otavio: we need to patch the recipes depending on lzma-native Mar 22 17:30:51 grep Mar 22 17:31:01 ant_work: sure sure Mar 22 17:31:07 there are not too many iirc Mar 22 17:31:15 linux-kexecboot is one Mar 22 17:31:19 ant_work: but we could drop it from bitbake at least and then do it for the remaining ones Mar 22 17:31:46 pls post the patch on ML Mar 22 17:32:03 ant_work: I haven't test it Mar 22 17:32:04 seem the best option today Mar 22 17:33:43 btw lzma -8 and xz -7 seeems to be the limits to be able to decompress on 32Mb devices Mar 22 17:35:43 btw btw somenone said Mar 22 17:35:46 "The levels 7 to 9 are particularly insane in this regard, while offering you a ridiculously tiny better compression ratio than mid-levels. " Mar 22 17:38:07 * woglinde will try kexec-boot on his ac100 Mar 22 17:38:10 later Mar 22 17:39:38 woglinde: if it is 240x320 you need a small fix... Mar 22 17:40:17 its 1024x600 Mar 22 17:40:27 or 800x400 Mar 22 17:40:31 ars 800x600 Mar 22 17:40:37 framebuffer Mar 22 17:40:45 np, you'll have black bands Mar 22 17:40:53 hehe Mar 22 17:40:57 theme.h is hardcoded 480x640 right now Mar 22 17:40:58 no prob for me Mar 22 17:41:03 patch pending... Mar 22 17:44:57 khem: in? Mar 22 17:45:15 Tartarus: yes I am here Mar 22 17:45:27 61f0980015f29d6050d6d44b8029b757978b51d6 in oe master Mar 22 17:45:36 Why did that drop filtering out the virtual bits? Mar 22 17:45:41 (trying to re-sync this bit with poky now) Mar 22 17:46:03 I would think we would want to filter out the virtuals and gettext/gettext-native Mar 22 17:46:34 Tartarus: are you bringin in 0.18 gettext to poky Mar 22 17:46:42 not yet Mar 22 17:46:48 I'm just fixing gettext.bbclass being broken Mar 22 17:47:03 hm what was broken? Mar 22 17:47:26 virtclass-native Mar 22 17:47:29 and some other corner cases Mar 22 17:47:36 ie all the un-fun I just had in oe :) Mar 22 17:48:00 got it Mar 22 17:48:03 ah Mar 22 17:48:11 hm whats poky now? Mar 22 17:48:13 khem, so should it filter them all out? Mar 22 17:48:17 an layer to oe-core? Mar 22 17:48:22 problem is that we dont use virtuals everywhere Mar 22 17:48:55 khem, stop using that word :) Mar 22 17:48:57 otavio you can update flash again Mar 22 17:49:01 10.2.153.1 Mar 22 17:49:11 Crofton: eh Mar 22 17:49:16 khem, right Mar 22 17:49:19 Tartarus: Yes I would think so Mar 22 17:49:22 ok Mar 22 17:49:26 I'll post to oe-core then, thanks Mar 22 17:49:45 Tartarus: but there is a catch 22 somewhere Mar 22 17:49:53 I think when building uclibc Mar 22 17:50:05 gettext needs libiconv and vice versa Mar 22 17:50:09 or some such Mar 22 17:50:21 hm yes Mar 22 17:50:44 right Mar 22 17:50:49 but that's the usual USE_NLS games Mar 22 17:50:52 no? Mar 22 17:51:01 (or not bringing in gettext.bbclass) Mar 22 17:51:21 Tartarus: actually that DEPENDS_GETTEXT should also be changed to virtual/libiconv virtual/libintl only Mar 22 17:51:36 w/o doing the bump to 0.18? Mar 22 17:51:47 yes bump is immaterial Mar 22 17:52:29 Well, hang on, heh Mar 22 17:52:30 if we have USE_NLS=no then all should be punted out Mar 22 17:52:40 We should filter them all out, yes Mar 22 17:52:49 But today we have gettext/gettext-native/virtuals in the DEPENDS_GETTEXT Mar 22 17:52:57 and I want to make any further cleanups a follow on patch I think Mar 22 17:53:02 and actually we should filter them out always Mar 22 17:53:04 right now I'm trying to fix coreutils-native in oe-core :) Mar 22 17:53:20 and readd DEPENDS_GETTEXT = "virtual/libiconv virtual/libintl" Mar 22 17:53:34 * khem is fixing fennec Mar 22 17:53:37 almost fixed Mar 22 17:53:55 http://pastebin.com/fgYKT0Dm Mar 22 17:53:57 is what I've got now Mar 22 17:53:58 its just my stupid box takes 3 hours to compile the damn fennec Mar 22 17:55:46 Tartarus: depending on gettext directly is not ok Mar 22 17:56:07 Tartarus: we should remove the explicit deps on gettext and add virtual/libintl instead Mar 22 17:56:21 Nobody does that yet Mar 22 17:56:30 we can do that in clas Mar 22 17:56:31 I just want to start by fixing oe-cores failures Mar 22 17:56:35 so it will work with uclibc Mar 22 17:56:36 Then we can enhance this stuff more Mar 22 17:56:45 otherwise someone pulls in gettext Mar 22 17:57:04 goal is if you can build x11-image with uclibc and it should not pull in gettext Mar 22 17:57:14 then you have succeeded Mar 22 17:57:14 Almost no recipes should have gettext/gettext-native in DEPENDS Mar 22 17:57:19 I think there's just one or two that must Mar 22 17:57:22 * Jay7 found bug in do_deploy wrt package_stagefile_shell Mar 22 17:57:27 And we've got that in oe.master Mar 22 17:57:35 still have no time to report.. Mar 22 17:57:39 And it's all managed via gettext.bbclass Mar 22 17:57:49 Tartarus: we add explicit deps in gettext.bbclass on gettext Mar 22 17:57:51 Jay7: bug or feature? Mar 22 17:57:53 it behaves wrong when DEPLOY_DIR_* is out of TMPDIR Mar 22 17:58:03 Jay7, ah that old feature :) Mar 22 17:58:06 wes, old issue Mar 22 17:58:12 Jay7: that's been reported 3 or 4 times on the list, i'd say Mar 22 17:58:17 s/issue/feature/ ;) Mar 22 17:58:19 package_stagefile_shell should have 2 args Mar 22 17:58:23 from and to :) Mar 22 17:58:34 khem, right, and filter out on USE_NLS, and then you just have the few USE_NLS_pn-foo = "yes" on uclibc Mar 22 17:58:35 ah, a new one, even Mar 22 17:58:40 due to badly behaving programs Mar 22 17:58:52 it's just the nature of the beast. pstage is implemented by installing the ipk into TMPDIR as the rootfs. if anything pstage captures is outside of TMPDIR, it won't work right. clearly you acn't install a package into a rootfs but have it include files outside the rootfs Mar 22 17:59:21 Tartarus: yes and depend on virtual/libilt in gettext.bbclass rather than gettext directly Mar 22 17:59:55 khem, my hesitation here comes from the 2 weeks of fall out from my "should be simple, lemme just push it" changes here last time Mar 22 18:00:11 So I really want to just start with getting oe-core up to +/- oe.master status quo Mar 22 18:00:14 yes gettext is always tricky Mar 22 18:00:19 and then we can try and improve further Mar 22 18:00:28 kergoth: but havind DEPLOY_DIR out of TMPDIR is right idea iirc :) Mar 22 18:00:43 Tartarus: oe-core as of now does not do uclibc Mar 22 18:00:46 Tartarus: I remember Gentoo's same discussion Mar 22 18:00:48 http://us.generation-nt.com/answer/gentoo-dev-virtual-libintl-virtual-iconv-help-190121301.html Mar 22 18:00:48 so you will be alright Mar 22 18:00:51 Jay7: it is, but you can't do it without breaking pstage, and it's not worth the trouble given pstage is going away Mar 22 18:00:56 as you have said, DEPLOY_DIR is result of build, not temporary thign Mar 22 18:00:58 but I think its better to fix it well in oe first Mar 22 18:01:05 khem: So, quick tangent, what's the quickest way to get a contrib branch done? Is the main contrib repo always in sync w/ oe-core and I just need to make my own branch? Mar 22 18:01:26 Tartarus: it doesn't matter whether or not its in sync, its just a place to put your branch, and they pull it Mar 22 18:01:40 ah DEPENDS_GETTEXT = "gettext-native virtual/libiconv virtual/libintl" Mar 22 18:01:43 kergoth: right, ok, i'm just having a git thinko I think then Mar 22 18:01:45 thats what I want Mar 22 18:01:47 cool Mar 22 18:01:48 me will test in a minute Mar 22 18:01:50 it just happens that the scripts default there for the pull request, you technically don't need it to be there at all Mar 22 18:02:21 git push git@git.openembedded.org:openembedded-core-contrib HEAD:my_nifty_branch Mar 22 18:02:43 * kergoth still keeps his in github for convenience Mar 22 18:02:44 Tartarus: you clone oe-core and push it into contrib Mar 22 18:04:48 Tartarus: add a remote repo git remote add contrib git@git.openembedded.org:openembedded-core-contrib Mar 22 18:05:20 Tartarus: then do git push contrib : Mar 22 18:05:31 k, thanks Mar 22 18:05:39 Tartarus: usually I create a local branch with same name Mar 22 18:05:45 kraj/xxxx Mar 22 18:05:51 and then push it to contrib repo Mar 22 18:06:14 Tartarus: once the patches are applied then you can delete the branches Mar 22 18:06:28 git push contrib :trini/xxx Mar 22 18:25:55 yay for send-pull-request -g, boo for not having seen it quicker Mar 22 18:28:57 Tartarus: heh, i just used create-pull-request and send-email. send-pull-request doesn't give you much beyond send-email afaict Mar 22 18:29:13 hmm Mar 22 18:46:08 Hi guys, I'm wondering -- is there any common method of packaging and distributing the native tool-chain? The best I've been able to come up with so far is building it once, tarring up the results and using assume_provided for all the native-* packages. The goal here is to provide my developers with a pre-built native toolchain so they can short-circuit that part of the build on a fresh checkout. Mar 22 18:46:34 see the meta-toolchain and external-toolchain recipes Mar 22 18:46:49 well, depends on what you mean by native in this context :) Mar 22 18:47:20 native being x86_64 or i386, the machine we're running the cross-compilers on Mar 22 18:47:43 I'll go take a gander at those recipes, thank you for answering - I appreciate it. Mar 22 18:51:57 there's no standard method for natives really, just as you say distribute and set assume provided as appropriate Mar 22 18:52:09 i do have a class that sets assume provided based on what's available on the build machine Mar 22 18:52:20 ahh Mar 22 18:52:23 maybe you could leverage that to automatically determine what was made available in the tarred bits Mar 22 18:52:29 so that'd be one less step Mar 22 18:52:52 https://gist.github.com/869616 Mar 22 18:52:59 Yeah, thats exactly what I'm shooting for -- if git is on the system I don't want to force folks to download/recompile it Mar 22 18:53:11 * kergoth nods Mar 22 18:53:19 I have a full build down to 1.2 hours so I'm trying to find anywhere I can shave more time off. Mar 22 18:53:22 you should *not* use anything like this for your reliable weekly builds or releases or anything obviously Mar 22 18:53:27 but its great for day to day dev stuff Mar 22 18:53:31 Agreed! Mar 22 18:53:46 i've been trying to determine which things are safe to assume Mar 22 18:53:51 but its an ongoing effort :) Mar 22 18:54:02 could very well blow up tomorrow if it turns out something relies on something more specific than i check for Mar 22 18:54:07 but if it works today i'm happy Mar 22 18:54:29 some things are very much not safe to rely on in the build machine, e.g. autoconf-native due to our patches Mar 22 18:54:45 of course if you do what you're talkinga bout, tarring up built native bits, that would be a way around that Mar 22 18:55:02 kergoth: may be we should just create safe-to-assume-providers. Mar 22 18:55:06 files Mar 22 18:55:29 and source them in after detecting the host distro Mar 22 18:56:32 khem: per distro could be a more sane approach. we really need version specific deps and the like, so we can be more specific about what we reuqire Mar 22 18:58:00 kergoth: we could use hosts package manager to help us Mar 22 18:58:03 nar: i use the above for all of my builds, oe, oe-core, and mentor graphics product. feel free to grab it and run with it for your own needs, let me know how it goes if you do :) Mar 22 18:59:11 kergoth, To use your patch, I include it in my classes directory -- do I just inherit it in my image recipe? Or should it go somewhere else? Mar 22 18:59:32 (just want to make sure I 'get it') Mar 22 19:00:03 nar: what i do is place those files in ~/.oe and add ~/.oe to my base BBPATH everywhere, personally Mar 22 19:00:19 then you can create ~/.oe/conf/site.conf for your per machine settings like parallel make too Mar 22 19:00:37 i actually have a common site.conf and it includes site/${HOSTNAME}.conf, wh ich isn't tracked by my homefiles git :) Mar 22 19:01:41 Hrm. I don't get how assume.py gets picked up -- is it that bitbake attempts to load everything with .bbclass? Mar 22 19:01:56 nar: current OE adds ./lib relative to each dir in BBPATH to sys.path Mar 22 19:02:06 and imports any module listed in the OE_IMPORTS variable automatically Mar 22 19:02:13 ahh Mar 22 19:02:20 this is how it finds the 'oe' python package (openembedded/lib/oe) Mar 22 19:02:47 Gotcha! Ok. Then I think your patch is exactly what I was looking for. You rock, sir. Mar 22 19:03:16 That'll probably get full OS builds down to 30 minutes for fresh views. Which will be awesome. Mar 22 19:03:22 https://github.com/kergoth/homefiles/tree/master/.oe is my personal setup, if anyone is curious. it also sets PARALLEL_MAKE and BB_NUMBER_THREADS based on the number of cores in the system multiplied by adjustment factors that can be overridden, also automatically reduces it if you're inside of vmware Mar 22 19:03:47 nice Mar 22 19:04:12 I will dig into it, definitely will be improvements. Mar 22 19:30:33 03Khem Raj  07master * rb319f91822 10openembedded.git/recipes/uclibc/ (3 files in 2 dirs): Mar 22 19:30:33 uclibc-git: Add FTS support and update to -rc3 Mar 22 19:30:33 Signed-off-by: Khem Raj Mar 22 19:30:36 03Khem Raj  07master * r22f72e1751 10openembedded.git/recipes/yasm/yasm_0.7.2.bb: Mar 22 19:30:37 yasm: Upgrade yasm_0.7.2.bb -> yasm_1.1.0.bb Mar 22 19:30:37 Signed-off-by: Khem Raj Mar 22 19:30:37 03Khem Raj  07master * ra2f8518e3f 10openembedded.git/recipes/cairo/ (cairo.inc cairo_1.10.0.bb): Mar 22 19:30:38 cairo_1.10.0.bb: Fennec will now need tee support in cairo so enable it Mar 22 19:30:38 Signed-off-by: Khem Raj Mar 22 19:39:43 kehm fts support? Mar 22 19:39:45 in uclibc Mar 22 19:39:47 ugh Mar 22 19:39:49 systemd Mar 22 19:43:05 typing...its a *fine* art Mar 22 19:44:15 crofton Crofton|work ping? Mar 22 19:48:44 pong Mar 22 19:50:25 OSUOSL is requesting a write up we can give them about the project for their webpage. Mar 22 19:51:06 oh jesus Mar 22 19:51:16 we ahve to find someone that can write? Mar 22 19:51:49 hm? Mar 22 19:51:58 Crofton|work, lol.....okay...jas I got an idea. Mar 22 19:52:04 :) Mar 22 19:52:51 http://www.socallinuxexpo.org/scale9x/exhibitors/openembedded Mar 22 19:52:55 would that work? Mar 22 19:53:19 that is a good start Mar 22 19:53:28 see if that works for them Mar 22 19:53:41 okay I will Mar 22 20:36:10 re stefan Mar 22 20:36:43 woglinde: I heard DE has lowest unemployment rate now Mar 22 20:36:50 woglinde: is that true ? Mar 22 20:36:51 anyone seeing a fetch failure on vala? Mar 22 20:37:05 khem hm really? Mar 22 20:37:08 since when? Mar 22 20:37:09 Crofton|work: mickey updated vala Mar 22 20:37:13 lately Mar 22 20:37:20 I jsut pulled Mar 22 20:37:33 Crofton|work: may be thats why Mar 22 20:37:42 woglinde: I read somewhere Mar 22 20:37:58 woglinde: I have shook hands with Frau Merckel in 2000 Mar 22 20:38:04 khem hm I only reading this news from time to time Mar 22 20:38:23 khem because you got a green card? Mar 22 20:38:49 woglinde: sort of I was one of those initial gnuea pigs Mar 22 20:39:32 but It was that I have to renew it every couple of years at Foreign office Mar 22 20:39:38 looks like the source file does not actually exist Mar 22 20:40:00 hmm Mar 22 20:40:14 maybe it is because freesmartphone.org is donw? Mar 22 20:40:35 ya Mar 22 20:40:36 yeah Mar 22 20:40:40 had to stop the webserver for a while Mar 22 20:40:40 :) Mar 22 20:40:44 trac spam is getting unbearable Mar 22 20:40:53 let me put it up again Mar 22 20:41:08 done Mar 22 20:41:16 thanks Mar 22 20:41:35 ah there we go Mar 22 20:41:46 no downtime possible now a days Mar 22 20:41:50 connected world Mar 22 20:53:35 boy isn't that the truth Mar 22 20:53:57 mickey| I had to lock down trac and only allow registered users to edit. Mar 22 20:54:13 how does that work? Mar 22 20:54:21 no, scratch that Mar 22 20:54:24 my problem is they register Mar 22 20:54:28 and then create bogus bugs Mar 22 20:54:34 so i would need to moderate registering Mar 22 20:55:11 mickey|, so what you need to do is what I did for OE... Mar 22 20:55:34 talk to me on IRC, email me, show me you are real and working on the project...THEN I'll give you access. Mar 22 20:55:44 *nod* Mar 22 20:56:43 damn spammers Mar 22 20:56:58 Crofton|work, yup Mar 22 20:57:05 making life HELL for others. Mar 22 21:27:30 ka6sox-work: do we still need captcha on edits then? Mar 22 21:27:58 Tartarus, thinking about removing that... Mar 22 21:28:23 those who I've designated as "human" shouldn't have to thought Mar 22 21:28:26 -t Mar 22 21:30:15 * Tartarus still has to, heh Mar 22 21:31:59 Tartarus, whats your user ID (pm me please) Mar 22 21:34:26 Crofton|work: oe wiki ? Mar 22 21:35:22 dcordes, I'm talking about the OE wiki. Mar 22 21:36:29 ka6sox-work: recaptcha plugin not helping ? Mar 22 21:37:37 khem: does fennec compile for you successfully after adding tee in cairo a2f8518e3f38f6533492865a3ed81deb5c26d75e ? Mar 22 21:38:06 ka6sox-work: we had some problems in htc-linux mediawiki until we created a custom bot challenge Mar 22 21:43:25 GNUtoo: did you see the autoconf213 problem was fixed ? Mar 22 21:43:42 ah ok nice Mar 22 21:43:43 thanks Mar 22 21:44:14 dcordes, sounds good...did you write a plugin? Mar 22 21:46:14 ka6sox-work: NetRipper did. he can be found in #htc-linux Mar 22 21:46:39 ka6sox-work: since we have it plus activated email confirmation for account creation, there is zero spam Mar 22 21:49:50 dcordes, sounds good...I'll try to make it over there soon...as you can imagine we are pretty busy. Mar 22 21:50:21 ka6sox-work: don't worry I will check this out for you. don't think there will be a problem about it Mar 22 21:51:10 dcordes, thanks..I'm 99% of the time hang around here. Mar 22 21:51:45 a good opportunity to give back for copying the oe wiki main page layout :D Mar 22 21:52:29 dcordes, ya, I liked it too...used it someplace too. Mar 22 22:03:41 ka6sox-work: I've updated buildstats page Mar 22 22:04:07 I've talk on #linaro with asac about similar things Mar 22 22:04:23 they have talk on ELC about this as well Mar 22 22:04:48 so I hope pidge and plars will talk together about this Mar 22 22:05:56 okay, I haven't heard if pidge will be @ ELC or not...I will be Mar 22 22:06:22 Jay7: tinderbox replacement ? Mar 22 22:06:45 dcordes: yes Mar 22 22:07:13 ka6sox-work: she have presentation from Yocto side about buildstats/runtime testing/etc Mar 22 22:07:20 Jay7: that will be nice for references on the mailing list Mar 22 22:07:35 dcordes: wait for fennec commmit :) Mar 22 22:07:43 dcordes: those were precursors Mar 22 22:07:52 dcordes: we are waiting for Yocto release to collaborate with yocto's people Mar 22 22:08:03 dcordes: I have really slow machine fennec takes more than 3 hrs to compile Mar 22 22:08:14 so its really time consuming Mar 22 22:09:01 khem: awesome! thanks so much I can't wait to finally bake an shr-image with fennec Mar 22 22:09:16 Jay7, okay then I'll be there for that. Mar 22 22:09:21 khem: I think it's important to have the program working well known to end users Mar 22 22:09:24 khem, are you going? Mar 22 22:09:53 khem: it took like 40 minutes for my machine to reach the tee compile err Mar 22 22:10:07 ka6sox-work: so, please contact with plars and asac from #linaro side and pidge from #yocto :) Mar 22 22:10:35 Jay7, please email this as I will forget. Mar 22 22:10:42 too much happening Mar 22 22:10:46 kitchen:take(pid(0,250,0), dog) Mar 22 22:10:51 heh... Mar 22 22:10:54 khem: so not sure how long it will take to compile it fully. but if you want to me to try any patch please don't hesitate Mar 22 22:11:07 ka6sox-work: please remind me your email :) Mar 22 22:11:16 Jay7: ok Mar 22 22:11:22 sent.. Mar 22 22:11:59 I am not certain what yocto is from the oe developer / user point of view Mar 22 22:12:21 * ka6sox-work is terrible @ explaining it. Mar 22 22:12:46 is oe-core a yocto fork of org.oe.dev ? Mar 22 22:12:46 okay back to flight code... Mar 22 22:14:00 no Mar 22 22:14:04 "the Yocto Project and OpenEmbedded have agreed to work together and share a common core set of metadata" Mar 22 22:14:22 read the whole news Mar 22 22:15:23 dcordes: OK good news is that I am able to compile Mar 22 22:16:43 dcordes: I will commit it now Mar 22 22:16:53 dcordes: you can try it and let me know if it works Mar 22 22:17:03 I have tried it on uclibc/eglibc arm Mar 22 22:17:03 * dcordes ready to pull and compile from clean tmp Mar 22 22:17:37 It was not easy to fix this beast Mar 22 22:17:46 hackin gcc is far easier Mar 22 22:18:00 :) Mar 22 22:18:08 heh Mar 22 22:18:16 then I have thumb1 issue with meta-oe gcc if you want :) Mar 22 22:18:26 * dcordes nods Mar 22 22:18:28 JaMa|Off: I will fix it Mar 22 22:18:54 folks should start using oe-core+meta-oe Mar 22 22:19:03 since thats where all fun will be happening Mar 22 22:19:10 * JaMa|Off is trying to use oe-core+meta-oe+meta-shr :) Mar 22 22:19:21 JaMa|Off: fantastic Mar 22 22:19:28 JaMa|Off: let me know if you need help Mar 22 22:19:34 not sure if my brain can handle so many branches Mar 22 22:19:44 dcordes: they are layers Mar 22 22:19:48 I'm also using the shre distro but only fro org.oe.dev Mar 22 22:19:50 dcordes: like 7 layer burrito Mar 22 22:19:55 s/shre/SHR/ Mar 22 22:20:04 ok :D Mar 22 22:21:31 dcordes: let me add patch header before I commit Mar 22 22:22:18 re ant Mar 22 22:23:31 hi Mar 22 22:24:30 khem: building gcc-cross for om-gta02 again to show you the error.. Mar 22 22:24:48 khem: btw are you using rm_work with oe-core? Mar 22 22:27:47 JaMa|Off: if one wants to compile decent shr-image with oe-core , how to set things up ? (I need to be where the fun will be happening as well as able to compile shr for my phone) Mar 22 22:27:59 khem: and here is the error from eglibc.. http://paste.pocoo.org/show/358002/ Mar 22 22:28:31 dcordes: if using shr makefile "make setup-shr-core" Mar 22 22:28:58 JaMa|Off: I am settings thing up manually Mar 22 22:29:13 no makefiles please. is it documented somewhere ? Mar 22 22:29:28 dcordes: but that will only prepare env and checkout everything.. Mar 22 22:29:28 or should I try to pull the information from the scripts Mar 22 22:29:55 dcordes: there is lot of work needed in meta-shr and I have few more patches for oe-core too (to be able to start build at all) Mar 22 22:30:02 dcordes: yes, read the makefile Mar 22 22:30:08 ok Mar 22 22:30:14 JaMa|Off: let me look Mar 22 22:30:36 JaMa|Off: you can read this http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/ Mar 22 22:30:41 it will help you Mar 22 22:31:18 I already did, but I don't see how it's related to my problem Mar 22 22:31:30 oh I mean for setting up shr Mar 22 22:31:35 not for fixing gcc :) Mar 22 22:31:39 03Khem Raj  07master * r3aaa064fbb 10openembedded.git/ (10 files in 4 dirs): (log message trimmed) Mar 22 22:31:39 fennec: Make it build on ARM eglibc/uclibc Mar 22 22:31:39 This patchset enables fennec to build again Mar 22 22:31:39 Upgrades to latest release tag Mar 22 22:31:39 Bunch of patches to fix uclibc build Mar 22 22:31:39 Disable few options notably --disable-elf-hack Mar 22 22:31:39 Add -L/usr/lib to LDFLAGS otherwise Mar 22 22:31:43 dcordes: there you go Mar 22 22:32:35 JaMa|Off: we can host meta-shr layer on oe.org if needed Mar 22 22:32:43 or atleast we can propose Mar 22 22:32:44 khem: ah.. I have similar setup and also wrote it in "SHR makefile" which does similar job to oebb.sh Mar 22 22:33:01 ok then please advertise it for your users Mar 22 22:33:07 khem: I have it in our SHR git.. Mar 22 22:33:17 ok Mar 22 22:33:26 khem: I'll when it's usable out-of-the-box Mar 22 22:34:12 khem: now I have still many recipes without LIC_FILES_CHKSUM or with LICENSE="unknown" etc.. Mar 22 22:34:38 khem: but I'm using it as something to work with oe-core Mar 22 22:35:10 JaMa|Off: I have seen that error before Mar 22 22:35:35 khem: thanks! I will first see if I can compile it with my setup then procede to build shr-image including it in order to test it on htcleo machine Mar 22 22:35:43 JaMa|Off: cool think of stuff you want in meta-oe Mar 22 22:35:52 khem hm how do we fix the typedef unsigned short sa_family_t; in linux/socket.h for uclibc-git? Mar 22 22:35:52 and propose it Mar 22 22:35:54 khem: after finishing cleaning stuff there and when resulting images are as good as with oe.dev, I'll start to push "shared" parts to meta-oe and then advertise only small meta-shr layer with really specific stuff Mar 22 22:35:59 khem I would prefer a sed Mar 22 22:36:11 woglinde: you need to patch the kernel headers Mar 22 22:36:22 for now I edit the file per hand Mar 22 22:36:29 JaMa|Off: sounds good Mar 22 22:36:35 khem why no sed in uclibc-git? Mar 22 22:36:41 JaMa|Off: ok now tell me which version of binutils are u using Mar 22 22:36:54 khem: the sysroot path thing seems to explain why it was looking for all those dependencies I had compiled already Mar 22 22:36:55 khem: 2.21 Mar 22 22:37:03 hmm ok Mar 22 22:37:09 and gcc is from meta-oe ? Mar 22 22:37:41 khem: yes and for nokia900 it builds ok Mar 22 22:37:51 yes since thats arm mode Mar 22 22:38:06 ok and eglibc ? Mar 22 22:38:10 khem: machine configs are the same as in oe.dev (where this combination also work fine) Mar 22 22:38:14 are you using one from oe or stock oe-core Mar 22 22:38:15 up eglibc Mar 22 22:38:17 yup Mar 22 22:38:42 khem and I know in libc-headers .37 its fixed Mar 22 22:38:43 eglibc from oe-core Mar 22 22:38:58 hm ah maybee I should put into my local.conf Mar 22 22:38:59 JaMa|Off: ok and this works all well in oe right ? Mar 22 22:39:11 because I am the only one who pitfalls over it Mar 22 22:39:11 woglinde: which headers are u uisng Mar 22 22:39:11 yes Mar 22 22:39:21 khem .32 is angstroem default Mar 22 22:39:41 woglinde: hmmm we need to change that to either .31 or .37 Mar 22 22:39:45 propose a fix for 2010 Mar 22 22:39:55 JaMa|Off: ok here is assignment for you Mar 22 22:40:11 try it with eglibc from oe Mar 22 22:40:13 khem ah no as I said I am the only one who pitfalls Mar 22 22:40:21 you need to import the recipes to meta-oe Mar 22 22:40:23 khem: I haven't checked *FLAGS/.bbclass diff between oe/oe-core wrt eglibc, but after last gcc change I did rebuild whole toolchain from oe for om-gta02 just fine Mar 22 22:40:36 args now its linux-libc-headers-2.6.31-r6: Mar 22 22:40:42 for qemuarm Mar 22 22:40:46 khem: ok, I'll try hopefully tomorrow Mar 22 22:40:48 JaMa|Off: right now gcc in oe-core is superset of oe and oe-core Mar 22 22:40:54 it has all goodies from both Mar 22 22:41:11 you men in meta-oe, right? Mar 22 22:41:14 mean Mar 22 22:41:20 JaMa|Off: eventually I will upgrade eglibc in oe-core soon Mar 22 22:41:27 JaMa|Off: yes meta-oe Mar 22 22:41:54 JaMa|Off: another thing you could try is add -Os to eglibc Mar 22 22:42:09 JaMa|Off: defaults in oe-core is to use O2 Mar 22 22:42:31 ok, that's something I can start now before going to bed.. Mar 22 22:42:38 alright Mar 22 22:43:04 * khem works on giving uclibc a facelift in oe-core Mar 22 22:44:36 khem: thanks Mar 22 22:44:39 gnight all Mar 22 22:44:42 gn Mar 22 22:44:46 nn Mar 22 22:44:56 dcordes: do u have decent box Mar 22 22:45:13 how long does it take you to build fennec Mar 22 22:45:24 oh well you will know its surpringly huge Mar 22 22:45:52 khem: as I'mr ebuilding everything from scratch... like 6hours .. Mar 22 22:46:05 ok Mar 22 22:46:20 I have not tested it runtime Mar 22 22:46:28 just made it to build Mar 22 22:47:09 khem: if it compiles to me I can report htcleo run time test status tomorrow morning Mar 22 22:57:53 03Otavio Salvador  07master * r653fddf050 10openembedded.git/bin/install: Mar 22 22:57:53 wrapper/install: add -t support Mar 22 22:57:53 Signed-off-by: Otavio Salvador Mar 22 22:57:53 Signed-off-by: Khem Raj Mar 22 22:57:55 03Otavio Salvador  07master * r2b9524714d 10openembedded.git/recipes/vlc/ (6 files): Mar 22 22:57:55 vlc: use INC_PR Mar 22 22:57:55 Signed-off-by: Otavio Salvador Mar 22 22:57:55 Signed-off-by: Khem Raj Mar 22 22:58:00 dcordes: all good ok Mar 22 22:58:01 03Peter Gsellmann  07master * rd851934ef5 10openembedded.git/recipes/gsoap/ (gsoap-native_2.7.13.bb gsoap_2.7.13.inc): Mar 22 22:58:01 gsoap_2.7.13 build errors, amendment Mar 22 22:58:01 [amendment to d641ae6bfd4303508c86db9285c2dcba28fb5474] Mar 22 22:58:01 recipes reformatted, removed tab characters Mar 22 22:58:01 Signed-off-by: Peter Gsellmann Mar 22 22:58:01 Acked-by: Paul Menzel Mar 22 22:58:02 Signed-off-by: Khem Raj Mar 22 22:58:04 03Kartik Mohta  07master * r6db4b9050e 10openembedded.git/recipes/libarchive/libarchive_2.8.4.bb: Mar 22 22:58:04 libarchive: Requires libxml2 Mar 22 22:58:04 Signed-off-by: Kartik Mohta Mar 22 22:58:04 Signed-off-by: Khem Raj Mar 22 22:58:14 03Otavio Salvador  07master * r4c6a9d421c 10openembedded.git/recipes/adobe-flash/flash-plugin_10.0.22.87.bb: Mar 22 22:58:14 flash-plugin: update to 10.2.153.1 Mar 22 22:58:14 Signed-off-by: Otavio Salvador Mar 22 22:58:14 Signed-off-by: Khem Raj Mar 22 22:58:16 03Otavio Salvador  07master * rcd43859fe0 10openembedded.git/recipes/vlc/vlc_1.1.4.1.bb: Mar 22 22:58:16 vlc (1.1.4.1): depends on lua5.1 Mar 22 22:58:16 Signed-off-by: Otavio Salvador Mar 22 22:58:16 Signed-off-by: Khem Raj Mar 22 23:13:58 good nite Mar 22 23:17:41 dcordes, I'd appreciate when you find out you tell me what you guys use... Mar 22 23:17:51 that would make my life easier. Mar 22 23:18:01 I have 18 wikis at last count to maintain. Mar 22 23:22:40 ka6sox-work: don't worry I won't forget you Mar 22 23:22:57 dcordes, thanks Mar 22 23:22:57 ka6sox-work: that's quite some wikis you maintain Mar 22 23:23:11 ka6sox-work: I'm happy with htc-linux wiki :) Mar 22 23:23:31 dcordes, good...glad to hear it...I like to hear those things. Mar 23 00:09:51 03Andrea Adami  07org.openembedded.dev * r004ff1e9a1 10openembedded.git/recipes/linux/linux-2.6.38/ (collie/defconfig poodle/defconfig): Mar 23 00:09:51 linux: edit fb font size for collie and poodle in 2.6.38. Mar 23 00:09:51 * 4x6 somehow inhibits kernel bootlogo (black screen) Mar 23 00:09:51 * 8x8 is fine on those devices Mar 23 00:09:51 Signed-off-by: Andrea Adami Mar 23 00:10:01 03Andrea Adami  07org.openembedded.dev * r2656515a55 10openembedded.git/recipes/linux/linux-2.6.37/ (4 files in 4 dirs): Mar 23 00:10:01 linux: remove unsupported 2.6.37 Zaurus defconfigs. We test 2.6.38 now. Mar 23 00:10:01 Signed-off-by: Andrea Adami Mar 23 00:10:02 03Andrea Adami  07org.openembedded.dev * r3eee915a36 10openembedded.git/recipes/linux/linux-kexecboot/ (6 files in 6 dirs): Mar 23 00:10:02 linux-kexecboot: remove obsolete 2.6.38-rc8 defconfigs in _git. Mar 23 00:10:02 * Let placeholder for the next 2.6.38+2.6.39-rc1. Mar 23 00:10:02 Signed-off-by: Andrea Adami Mar 23 00:14:29 03Andrea Adami  07org.openembedded.dev * r8d98b7e983 10openembedded.git/recipes/linux/linux-kexecboot-2.6.38/ (collie/defconfig poodle/defconfig): Mar 23 00:14:29 linux-kexecboot: edit fb font size for collie and poodle in 2.6.38. Mar 23 00:14:29 * 4x6 somehow inhibits kernel bootlogo (black screen) Mar 23 00:14:29 * 8x8 is fine on those devices Mar 23 00:14:29 Signed-off-by: Andrea Adami Mar 23 00:25:40 03Andrea Adami  07org.openembedded.dev * r65fd766e89 10openembedded.git/recipes/linux/ (3 files in 3 dirs): Mar 23 00:25:40 linux-kexecboot: edit fb font size in older 2.6.2x kernels. Mar 23 00:25:40 * bootlogo should now be shown on collie and poodle Mar 23 00:25:40 * tosa has height 640! Increase font size to 8x16. Mar 23 00:25:40 Signed-off-by: Andrea Adami Mar 23 00:34:37 03Andrea Adami  07org.openembedded.dev * r07481d5108 10openembedded.git/recipes/linux/linux-2.6.30/tosa/defconfig: Mar 23 00:34:37 linux: upddate 2.6.30 defconfig for tosa (fb font size). Mar 23 00:34:37 * use 8x16 fonts as other defconfigs Mar 23 00:34:37 * Deprecated: 2.6.38 is in testing Mar 23 00:34:37 Signed-off-by: Andrea Adami Mar 23 01:49:44 anyone messed with dulwich or pygit2, by chance? Mar 23 02:44:26 | NOTE: Fetch svn://developer.imendio.com/svn/gconf-dbus;module=trunk;proto=http | ERROR: Function 'Fetch failed: Unable to fetch URL svn://developer.imendio.com/svn/gconf-dbus;module=trunk;proto=http from any source.' failed | svn: OPTIONS of 'http://developer.imendio.com/svn/gconf-dbus/trunk': could not connect to server (http://developer.imendio.com) | NOTE: package gconf-dbus-2.16.0+svnr641-r0: task do_fetch: Failed Mar 23 02:44:36 how it fix **** ENDING LOGGING AT Wed Mar 23 02:59:57 2011