**** BEGIN LOGGING AT Tue Aug 18 02:59:56 2009 Aug 18 04:06:08 03Denys Dmytriyenko  07org.openembedded.dev * r44445fe59d 10openembedded.git/ (3 files in 3 dirs): Aug 18 04:06:08 dm6467t-evm: add "new" 1GHz DaVinci DM6467 machine Aug 18 04:06:08 Signed-off-by: Denys Dmytriyenko Aug 18 04:11:10 03Denys Dmytriyenko  07org.openembedded.dev * r930bbd0f24 10openembedded.git/ (2 files in 2 dirs): Aug 18 04:11:10 da830-omapl137-evm: add DA830/OMAPL137 machine Aug 18 04:11:10 Uses default linux-davinci kernel from Arago Project for now Aug 18 04:11:10 Signed-off-by: Denys Dmytriyenko Aug 18 04:12:54 03Denys Dmytriyenko  07org.openembedded.dev * r0490edf988 10openembedded.git/recipes/linux/linux-davinci/ (4 files in 4 dirs): linux-davinci: update defconfigs for dm355, dm365, dm6446 and dm6467 Aug 18 07:37:05 <_dash__> Hi all Aug 18 07:39:26 <_dash__> Please correct me if I am geeting wrong ... I have compiled toolchain with bitbake met-toolchain Aug 18 07:39:31 <_dash__> ist it right ? Aug 18 07:40:38 mickeyl: hey, can you do me favor? ack the package_tar.bbclass change to make it work again? Aug 18 07:42:17 <_dash__> Can I distribute toolchain compiled with bitbake meta-toolchain in my team ? Aug 18 07:49:34 _dash__: you should Aug 18 07:49:48 <_dash__> zecke: Thanks Aug 18 07:49:49 _dash__: moving binaries from one distro to another is always a bit icky on linux though Aug 18 07:49:54 <_dash__> I have done that Aug 18 07:50:13 <_dash__> yep Aug 18 07:51:06 <_dash__> zecke: But I am also facing one problem ... I want to distribute mplayer code also which should get compiled on different machines not having bitbake Aug 18 07:51:45 <_dash__> I have compiled mplayer code on machine successfully Aug 18 07:52:21 <_dash__> if I make archive of mplayer and toolchain and distribute it then same thing not getiingxompiled on others machine Aug 18 07:55:06 <_dash__> I think ccache is doing problem Aug 18 07:57:13 _dash__: without seeing the problem I can not say much... is your toolchain having all the dependencies that mplayer needs? Aug 18 07:57:31 <_dash__> yup Aug 18 07:58:05 <_dash__> ehat is ccache b4 toolchain prefix ? Aug 18 07:58:17 <_dash__> what is purpose odf ccache ? Aug 18 07:58:25 <_dash__> *of Aug 18 08:03:05 Goodmorning Aug 18 08:03:37 I'm trying to create a dir with 700 permissions from a recipe Aug 18 08:04:33 In the work dir it ends up with 700 rights, but in the rootfs it doesnt, there it is 775 Aug 18 08:05:06 _dash__: no idea what you are after, google will tell you what ccache is... in which way is mplayer compilation failing for others? Aug 18 08:05:46 Has anyone an Idea what can be wrong? Aug 18 08:09:39 tsjsieb: looks like the packaging tool does not honor these perm... what you can do is having a postinst hook Aug 18 08:12:02 O.k thanks, so then I should be able to 'chmod' the permissions of that dir after the rootfs has been filled? Aug 18 08:25:00 zecke: Do I understand correct that a postinst script is run on the development pc after creating the image, so I should be able to see if the result is correct now? Aug 18 08:26:08 (I added the postinst script to the package recipe, and not to the image recipe) Aug 18 08:26:22 Morning, anyone about who can give me a pointer on the 'right' way to do something (so that it stands a chance of getting added to GIT)? In this case I want to refactor the XFCE stuff so that we can build 4.4.* and 4.6.* images but this really means extra tasks, a new sample image for 4.6 and some renames, does that seem reasonable? Aug 18 08:26:38 tsjsieb: the postinst script of a package is ran after installation... in the case of a image it is ran after first boot Aug 18 08:27:31 o.k. Thank you. :) Aug 18 08:57:20 Hi, a library I wrote that is needed for the app I'm doing gets compiled and all, but not included in the image automatically. What am I missing? No luck with google... Aug 18 08:58:02 ballon: so you have DEPENDS in your app recipe for the lib, and your app is linking to the library? Aug 18 08:58:35 ballon: OE will look at the SO_NEEDED (objdump -x binary | less), and automatically add dependencies based on that Aug 18 08:58:40 good morning Aug 18 09:03:10 zecke: I have a DEPENDS and a RDEPENDS (well, actually it's not my app but I'm taking over...) Aug 18 09:04:39 ballon: and the application is linking to the library? the app gets installed to the image but the linked library does not? Aug 18 09:04:52 ballon: and OE is not warning you that it is linking to something it doesn't know? Aug 18 09:04:56 and the app is itself a library (QT plugin), but objdump -x lists the other library, yes Aug 18 09:05:23 as "NEEDED" Aug 18 09:07:01 zecke: not as far as I've seen, but maybe I've just missed it. Where should I look for it? Aug 18 09:11:54 ballon: I asked if the "plugin" gets installed? and the problem is that a dependency doesn't? Aug 18 09:13:19 sorry. yes, exactly Aug 18 09:14:13 a custom dependency, so I thought the recipe was just missing something but can't figure out what Aug 18 09:16:07 ballon: I don't have enough information to really say something. the OE code to detect dependencies is quite mature... if it fails to resolve a dependency it will print a warning... Aug 18 09:16:21 ballon: look at the generated ipk file to see what it "Depends: " on Aug 18 09:18:57 using what? i'm new to ipk so i'm not familiar with what tools do what Aug 18 09:19:37 I'm using midnight commander.. with a custom mc.ext :) Aug 18 09:20:12 well, i'm not =) Aug 18 09:20:20 ballon: effetcively a ipk is a deb file. two tar.gz (DATA and CONTROL) joined together with ar Aug 18 09:20:50 ballon: so ar -x the.ipk; tar xvzf DATA.tar.gz will give you a debian/ directory, and this contains the control file listing the dependencies Aug 18 09:21:06 ballon: (or you can look in the Packages file that is in the dir of your packages) Aug 18 09:21:44 (and to avoid weird kind of events, I would bump the PR/PV of the package to make sure I look at the right package) Aug 18 09:30:06 zecke: the one i'm looking at depends correctly Aug 18 09:31:22 ballon: then the library is installed... Aug 18 09:31:34 ballon: or this package didn't get installed Aug 18 09:32:10 very weird then, since the library is not on the image, but the app is Aug 18 09:32:49 ballon: the app is, but was the package you looked at installed? Aug 18 09:32:53 i bumped the revisions and issued a rebuild anyhow, but it will take a while for it to complete. maybe it works... Aug 18 09:33:09 how can i tell the difference? Aug 18 09:33:37 ballon: there is a log file for the image population... look at it :) Aug 18 09:33:54 ballon: see if the package you expected was installed, look if the library was not installed Aug 18 09:36:49 zecke: which log specifically? (assume i'm stupid enough to not find the right one, i might be =)) Aug 18 09:37:18 i do get a weird note when building the image Aug 18 09:37:44 NOTE: Not creating empty archive for -1.0-r3.1 Aug 18 09:38:13 and Aug 18 09:38:21 NOTE: Couldn't find shared library provider for .so Aug 18 09:43:01 ballon: first, take out your bogus RDEPENDS entry Aug 18 09:43:34 ballon: 2nd install the lib... in do_install() and make sure that FILES_${PN} is pointing to the lib... (check bitbake.conf for the defaults) Aug 18 09:43:51 ballon: 3rd the last error will automatically go away... Aug 18 09:51:06 Another question, what is the 'cleanest' way to tell a task (or anything) to use a version of a package > or < a specific version (the Gentoo way does not seem to work and I can't find a good example after a quick search/grep)? Def-pref is not really suitable in this case. Aug 18 09:54:11 DJWillis: the cleanest way would be to patch bitbake to understand versioned depends, but I guess this is probably not the answer you wanted. Aug 18 09:54:26 pb__: oh it understands them, it doesn't act on it :) Aug 18 09:57:31 pb__: no, it's the answer I feared ;-), I am rapidly giving up on 'doing it right' ;-). Aug 18 09:58:00 Trying to get XFCE 4.4.* and 4.6.* to coexist is a proving a pain Aug 18 09:59:56 zecke: sorry, didn't help. the lib is built and everything looks fine in the work-dir, but bitbake still outputs those messages Aug 18 10:00:17 i'm thinking it's something shlibs-related, but what do i know? Aug 18 10:00:57 DJWillis: if there's a particular binary attribute that you are trying to model, a hacky way to solve the problem would be to add a new virtual package representing it. Aug 18 10:01:38 for example, if foo 2.5 and later are "good enough" for some program, you could add PROVIDES = virtual/less-sucky-foo to the appropriate bb files and make your other packages depend on that virtual. Aug 18 10:02:22 obviously this doesn't really scale: you wouldn't want to have to do that for every version if you have two packages that proceed in lock-step. but, in some cases it can work. Aug 18 10:03:20 pb__: yep, it just seems 'hackish', i'll ponder it, I was trying to come up with a nice way to do it but that may work I guess (in a fashion). Your right however, not sure how it's going to scale. Aug 18 10:03:47 DJWillis: I don't think there is any nice way to solve that problem without surgery to bitbake itself. Aug 18 10:04:00 this is, unfortunately, a long standing bitbake deficiency. Aug 18 10:04:36 ballon: if you get "not creating empty archive for..." then your problem is with FILES, not shlibs. Aug 18 10:04:59 it's possible that you might have a shlibs problem as well, but it is futile to try to debug that while your packaging is broken since the former depends on the latter. Aug 18 10:05:49 unfortunately, if your package is so confidential that even its name is secret, there is probably not much that anybody else can do to help you fix it. I think you will have to debug this yourself. Aug 18 10:05:57 so what's wrong with FILES_${PN} += "${libdir}/libxxxx.so" Aug 18 10:06:05 ballon: sorry, it is as simple as the error message... Aug 18 10:06:12 pb__: I guess lots of virtual/xfcebits is going to get to be a right mess :(. I'll just DEFAULT_PREF them for 4.4 for everyone bar the Pandora ;-) (for now, until I figure something better), shame as it makes the recipies hard to get upstream but I do not have the willpower to open up BitBake ;-) Aug 18 10:06:24 ballon: nothing got installed... so the package ${PN} is empty Aug 18 10:06:33 i don't know how confidential it is, i just don't want to risk getting any heat for putting it out there Aug 18 10:06:41 ballon: well, in most cases libxxx.so is a development file (and belongs in ${PN}-dev), not the library itself. Aug 18 10:06:58 ballon: do you use qmake to build the library? Aug 18 10:07:34 ballon: by default you don't need to touch FILES_${PN}... this is why i refered to the bitbake.conf Aug 18 10:07:53 apart from that, there's nothing wrong with that FILES_${PN} on its face, but it's impossible to say from that single line whether it is actually the right thing to set. Aug 18 10:08:16 zecke: actually I have no idea since I didn't write these but am just taking over, i'll look it up Aug 18 10:09:43 ballon: to continue where pb stopped.. libxxx.so is normally a symlink... (not in the case of plugins) Aug 18 10:10:26 ballon: my current bet is... you shouldn't set the FILES_${PN}... and your do_install() {} is not installing anything Aug 18 10:11:02 i do get a tmp/work/xxxx/usr/lib/libxxxx.so when running bitbake Aug 18 10:11:27 ballon: that sentence didn't make any sense. :) Aug 18 10:12:04 =) Aug 18 10:12:48 the .so-file is where i myself expect it to be, but i'm new to oe (obviously) Aug 18 10:15:49 ballon: then share the location... and as pb__ pointed out.. libxxx.so is very unconventional (to not say wrong) for a library name :) Aug 18 10:17:42 ballon: I don't know the exact order but first "do_install() {}" will be called, libraries should be installed to ${D}${libdir}, afterwards do_package comes by. it is looking at the "PACKAGES" variable and the moving files out of the "${D}" directory to the package dir according to the glib in FILES_PACKAGE_NAME Aug 18 10:23:11 zecke: it creates a dbg, and a dev-package, but not a regular package Aug 18 10:23:28 share what location? Aug 18 10:28:16 pb__: thinking about my version stuff, do you think something like virtual/xfce44_libblah and virtual/xfce46_libblah would stand a chance of getting upstream? Aug 18 10:28:44 ballon: -dbg and -dev packages will be created even if they are empty. Aug 18 10:29:01 ballon: but the -dbg package will not be empty if the library was installed Aug 18 10:29:23 ballon: and I have the feeling you are not really listening Aug 18 10:31:18 DJWillis: yeah, given that there is no better solution I can't see any reason why not. Aug 18 10:31:49 zecke: oh i'm trying to listen as hard as i can Aug 18 10:31:59 really Aug 18 10:33:04 ballon: in the workdir of the "library" you will have: a "image" folder Aug 18 10:33:38 ballon: is your library in image/usr/lib/libxxx.so.*? is the library name really libxxx.so (as we said that looks fishy by itself) Aug 18 10:34:29 yes, it is, and no it's not named xxxx, i'm just not sure if the name is sensitive or not at this stage Aug 18 10:35:43 ballon: ignoring the xxx bit, does the name of your shared library genuinely end in the three characters ".", "s" and "o"? Aug 18 10:35:46 ballon: the .so part is bad Aug 18 10:35:53 generally there would be a version suffix after that, libzecke.so.1.2 or some such Aug 18 10:35:57 ballon: it should be .so.X.Y.Z and the rest being symlinks Aug 18 10:35:59 yes, it's named .so, no numbers Aug 18 10:36:13 okay. in that case it is probably landing in the -dev package. Aug 18 10:36:27 have you inspected the contents of ${PN}-dev.ipk to see what's in there? Aug 18 10:36:39 and yes, i know that's not the convention but i didn't write the lib i'm just trying to get it to package properly Aug 18 10:38:34 the dev-package has a data.tar.gz that contains the .so file (under /usr/lib) Aug 18 10:39:42 okay, that would be your problem then Aug 18 10:40:31 alright, so what's the solution? just make the app depend on -dev instead? Aug 18 10:40:39 you'll need to adjust FILES_${PN}-dev so that it doesn't steal away the .so file Aug 18 10:41:20 ok, so just override it with an empty string then? Aug 18 10:41:37 if you genuinely don't have any development files, yes Aug 18 10:42:02 obviously you won't get a -dev package then, but that might not matter in your application. Aug 18 10:42:23 i guess there are some .h-files that should be in there Aug 18 10:43:02 probably the best thing would be to start with the default value (see bitbake.conf) and just remove the part that mentions the .so file Aug 18 10:43:21 * XorA wonders where python hides the locale module Aug 18 10:44:51 pb__: seems to work with empty string as far as i can tell without building the actual image Aug 18 10:45:25 so obviously this is a hacky way to get it to work, where can i learn how to do it properly? Aug 18 10:45:51 i guess the lib itself is nothing more than a hack anyhow, but still... Aug 18 10:48:47 hmm, sorry, i was being hasty. bitbake created the package, but it was empty when i unpacked it =/ Aug 18 10:49:14 given the library that you have to work with, the most "proper" solution is what I suggested: set FILES_${PN}-dev to the default value, less libxxx.so. Aug 18 10:49:26 completely empty? that seems unlikely, since bitbake will generally not create archives if they would be empty. Aug 18 10:49:32 what does "tar tzf data.tar.gz" say? Aug 18 10:50:13 it says nothing Aug 18 10:50:52 sorry, i was being retarded. i typed xzf instead of tzf Aug 18 10:50:55 that is strange. you didn't set ALLOW_EMPTY or anything like that, presumably? Aug 18 10:50:55 everthing was fine Aug 18 10:50:57 ah Aug 18 10:53:15 i finally found the correct bitbake.conf, and it all makes a lot more sense to me now Aug 18 10:53:49 the whole problem was the naming of the .so (no numbers) Aug 18 10:54:00 thanks a lot for your patience =) Aug 18 10:54:32 the structure is a bit confusing when you're unfamiliar... Aug 18 10:54:45 lot of "magic" going on Aug 18 10:57:29 is the OE repo sometimes repacked? because I think it's getting slower and slower to git clone etc. from it? Aug 18 11:10:56 th1_: manually repacked... Aug 18 11:13:07 on the old installation we ran git gc --auto in a cron job Aug 18 11:34:40 zecke, should we ping cbrake about that? Aug 18 11:37:04 hmm, for some reason the package is not included in the image, forcing it in seems ugly but will have to do for now Aug 18 11:37:16 good morning everyone Aug 18 11:41:21 hi rkirti Aug 18 11:41:41 brb, food :) Aug 18 11:50:02 Crofton|work: yes, do we have an admin mailinglist? do we coordinate outside of the /README file? Aug 18 11:51:43 not that I know of Aug 18 11:52:14 the dev list should be fine, the more people that know how stuff works the better :) Aug 18 11:57:46 right, it would be a shame to create another oe-cabal list so soon. Aug 18 11:59:44 pb__, how do you know their isn't one :) Aug 18 12:00:00 heh, good point Aug 18 12:00:33 but, what I said earlier still stands Aug 18 12:00:48 pb__, thanks for offering Cambridge Aug 18 12:00:55 what is too many people? Aug 18 12:03:12 if we did it at my offices, I guess we could probably fit 20-30 people in relative comfort. more than that would be tricky here without a lot of disruption, though I might be able to find a bigger space somewhere else. Aug 18 12:03:30 how many people attended the last oedem? Aug 18 12:03:42 less than 20 Aug 18 12:03:47 good morning, btw Aug 18 12:03:53 mickeyl: good morning! Aug 18 12:04:00 okay, that should be fine then. Aug 18 12:04:04 although i expect this year to see more, i don't think we would exceed 30 Aug 18 12:04:25 all depends on travel costs Aug 18 12:05:00 mickeyl: righto, fine. Aug 18 12:05:10 * XorA would love cambridge as a venue Aug 18 12:05:15 not sure that I actually have thirty chairs here, but I guess I can borrow some from elsewhere :-} Aug 18 12:05:32 as long as pb__ takes us on the pub tour :-) Aug 18 12:05:37 heh Aug 18 12:05:47 I remeber some nice pubs last time I visited Aug 18 12:05:51 the big headache is the silly money :) Aug 18 12:06:34 http://www.cambridge-pubs.co.uk/map.gif has a useful map Aug 18 12:06:49 I think most of those are still open although some of them have different names nowadays Aug 18 12:07:07 pb__: should gps all the pubs these days :-) Aug 18 12:07:43 where is gatwick? Aug 18 12:07:44 I remember spending a lot of time sitting near water Aug 18 12:07:50 Crofton: south of london Aug 18 12:07:55 Crofton: the other side of london. heathrow or stansted are better. Aug 18 12:08:22 gatwick is ok though in extremis, and it does tend to be cheaper than the others. Aug 18 12:09:11 at least at gatwick security checkin doesnt take 2 hours due to total idiots manning the scanners Aug 18 12:09:31 * XorA has vowed to never fly to Stanstaed again Aug 18 12:09:40 even though my aunt live next to the airport Aug 18 12:09:46 It takes two hours due to the evil and sadistic people manning the scanners? Aug 18 12:10:18 twice I have travelled from Stanstead recenctly and they have only had one xray machine Aug 18 12:10:19 XorA: I dunno, I find they're all about as bad as each other. thanks, dr reid! Aug 18 12:10:33 one...... one for a major london airport Aug 18 12:10:38 at its quitest, edin has 4 Aug 18 12:11:06 I had to sprint for the plane even though I was two hours before takeoff Aug 18 12:11:18 heh, that does sound fairly bad Aug 18 12:11:46 I used to like flying from Stanstead :-( Aug 18 12:12:42 ah well, think of the benefit to your carbon footprint :-} Aug 18 12:44:38 pb__: could you ack, my package_tar.bbclass change? Aug 18 12:45:07 zecke, I would, but I am real curious how it got broke Aug 18 12:45:19 and I do not understand that stuff well Aug 18 12:45:54 Obviously I was hoping someone who understood the history would comment :) Aug 18 12:46:26 Crofton: itself didn't broke... image.bbclass is doing inherit rootfs_${TYPE} Aug 18 12:46:42 Crofton: so depending on the order of INHERIT... it will be either package_ipk or package_tar... Aug 18 12:47:05 Crofton: I went through the history and we never had a rootfs_tar.bbclass within classes/, so my story is that it never worked Aug 18 12:47:31 I've done this before Aug 18 12:47:32 once Aug 18 12:47:39 like 18 months ago ..... Aug 18 12:48:22 Crofton: INHERIT += "package_ipk package_tar" should work Aug 18 12:48:36 Crofton: INHERIT += "package_tar package_ipk" will not work Aug 18 12:49:11 (not work as in parse errors) Aug 18 12:49:27 likely what happened Aug 18 12:50:12 ok, I'll ack in a bit Aug 18 12:50:18 I do not like to ack blindly Aug 18 13:04:17 zecke, I acked Aug 18 13:04:29 you convinced me you are not crazy :) Aug 18 13:05:26 Crofton: wow? Aug 18 13:05:47 that doesn't sound right Aug 18 13:07:50 well Aug 18 13:07:59 make that the reasoning for the change seems sound Aug 18 13:08:10 and meshes with my experience Aug 18 13:08:27 in that it works if the ordering was lucky Aug 18 13:10:31 * DJWillis starts to hate incestuous, ouroboros, virtual packages. Esp when he is the one who has created the monsters :-o Aug 18 13:12:33 is it possible to have more than one machine target and build for both from the same "generic" packages, in the same tmp tree? Aug 18 13:13:12 th1_: yes, google for multimachine, or see the angstrom website Aug 18 13:13:17 thanks Aug 18 13:21:23 pb__: do you still remember matchbox and xcompmgr? Aug 18 13:28:10 Can anyone suggest a good example of the differances between RPROVIDES and PROVIDES? I would assume if you wanted to provide a virtual package you could DEPEND on elsewhere that would work if you RPROVIDES'ed it? Aug 18 13:28:26 R is runtime Aug 18 13:28:33 the other one is compile-time Aug 18 13:28:58 you can't depend on virtual/$something at runtime, dpkg chokes on / Aug 18 13:29:06 there is a bug in the bug tracker about it Aug 18 13:29:12 Laibsch: that's how I understand it, trying to work out the right mix to solve my problem, that is what is baking my head ;-) Aug 18 13:29:28 yeah, it can be complicated at times Aug 18 13:29:28 Laibsch: ahhh, answers that then :(, back to square one. Aug 18 13:29:43 I helped myself with virtual-$something Aug 18 13:29:56 You should really take a look at that bug and the fixes associated with it Aug 18 13:31:06 Laibsch: trying to sort out a virtual/xfce**-package so OE can build both 4.4.* and 4.6.* and it is really making my head hurt. Easy to put 4.6.1 over the top but then any users of 4.4 are stuffed (and there seems to be a lot in shipping devices). Aug 18 13:31:57 if virtual/xfce is runtime, then I suggest to replace it everywhere with virtual-xfce and bump PR Aug 18 13:32:10 Laibsch: my worry is I am trying to do this with an aim of pushing to live. One hackaround I guess is just to call all the 4.6.* recipies xfce46-blah ;-) Aug 18 13:33:00 Laibsch: there is no concept of virtual/xfce, I am trying to workout a way to add something like it so diff versions can co exist. Aug 18 13:36:15 zecke: I guess I do. Aug 18 13:37:23 DJWillis: the "virtual/" doesn't really mean anything, it's just a convention. for runtime, we say "virtual-foo" rather than "virtual/foo". Aug 18 13:38:57 but, you can call your virtual packages anything you like, neither bitbake nor opkg performs any kind of computation on the names. Aug 18 13:40:51 pb__: does running xcompmgr just before matchbox should do the trick? Aug 18 13:41:18 zecke: I don't think the ordering should matter. You just need to make sure that matchbox's internal compositor is turned off. Aug 18 13:42:25 pb__: that's good to know. Aug 18 13:43:39 pb__: thanks Aug 18 13:43:53 DJWillis: the only reason for the prefix is to avoid accidental collisions between virtual and concrete packages. "bad shit", to use a technical term, tends to break loose if you have a particular package with both virtual and concrete embodiments. Aug 18 13:46:15 pb__: well in this case I will, libblah1.0 will provide virtual-xfce44-libblah and libblah2.0 will provide virtual-xfce46-libblah, does that make some sort of sense or am I still missing something more basic? Aug 18 13:46:54 pb__: the whole thing has 'bad mojo' wrtten all over it ;-) Aug 18 13:47:22 DJWillis: yeah, that's fine Aug 18 13:51:22 pb__: it's getting into a mess when you get the fact that virtual-xfce44-blah needs a DEPEND on virtual-xfce44-moose to build and some other package needs to RDEPEND on it so in that case should I RPROVIDES and PROVIDES so it has a build and runtime existance? Aug 18 13:51:41 pb__: sorry for all the questions, I know it's a cop out ;-) Aug 18 13:52:55 03Graeme Gregory  07org.openembedded.dev * r3942e499ae 10openembedded.git/ (15 files in 3 dirs): firefox_3.5.2.bb : add newest version of firefox Aug 18 13:52:55 03Graeme Gregory  07org.openembedded.dev * rdef77542ad 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.org/openembedded into org.openembedded.dev Aug 18 13:54:30 DJWillis: yes, you probably need both in that situation Aug 18 14:02:04 03Klaus Kurzmann  07shr/import * r166ef044bd 10openembedded.git/recipes/networkmanager/ (files/nm-system-settings.conf networkmanager_0.7.1.bb): Aug 18 14:02:04 networkmanager_0.7.1: add missing stuff to make it usable Aug 18 14:02:04 Signed-off-by: Klaus Kurzmann Aug 18 14:11:00 does anybody use x11-image for qemuarm? I have problems with hanging system after boot Aug 18 14:11:15 in stable/2009 Aug 18 14:12:16 I'm not using stable Aug 18 14:12:24 But I basically have the same problem in .dev Aug 18 14:14:55 03Michael Smith  07org.openembedded.dev * r76b6179494 10openembedded.git/recipes/nasm/nasm_0.98.38.bb: Aug 18 14:14:55 nasm: fix COMPATIBLE_HOST to match any vendor Aug 18 14:14:55 On x86_64, it was looking for x86_64-linux, not x86_64-blah-linux; Aug 18 14:14:55 it broke the build for syslinux if a BUILD_VENDOR was set. Aug 18 14:14:55 Signed-off-by: Michael Smith Aug 18 14:14:57 Signed-off-by: Holger Hans Peter Freyther Aug 18 14:15:07 03Michael Smith  07org.openembedded.dev * rb0f102c5b7 10openembedded.git/recipes/mtools/mtools_4.0.10.bb: (log message trimmed) Aug 18 14:15:07 mtools: don't install-info; fixes build on non-Debian hosts Aug 18 14:15:07 The install-info installed into staging by dpkg-native looks for Aug 18 14:15:08 /var/backups/infodir.bak and /usr/share/base-files/info.dir on Aug 18 14:15:10 the build system. On Debian/Ubuntu this is benign, but on other Aug 18 14:15:12 distros these files don't exist and the install fails. Aug 18 14:15:12 The system hangs just after "Configuring hal" Aug 18 14:15:14 The info file is still installed, we just don't try to rebuild the Aug 18 14:15:16 03Jonathan Cameron  07org.openembedded.dev * r41be021c38 10openembedded.git/recipes/glibc/ (glibc_2.7.bb glibc_2.9.bb): Aug 18 14:15:19 glibc 2.7 and 2.9 (arm): Remove unnecessary asm/page.h include Aug 18 14:15:21 Fix compile bug for arm with recent kernel headers Aug 18 14:15:23 ../ports/sysdeps/unix/sysv/linux/arm/ioperm.c:48:22: error: asm/page.h: No such file or directory Aug 18 14:15:50 Signed-off-by: Jonathan Cameron Aug 18 14:15:50 Signed-off-by: Holger Hans Peter Freyther Aug 18 14:15:50 03Holger Hans Peter Freyther  07org.openembedded.dev * r7861be0ddd 10openembedded.git/classes/package_tar.bbclass: (log message trimmed) Aug 18 14:15:51 package_tar.bbclass: Do not set IMAGE_PKGTYPE to unbreak parsing Aug 18 14:15:53 image.bbclass is trying to inherit package_${IMAGE_PKGTYPE} and Aug 18 14:15:55 this will fail because a rootfs_tar.bbclass doesn't exist. When Aug 18 14:15:57 planning to build images one needs to inherit package_ipk, Aug 18 14:15:59 package_rpm or package_deb in addition to INHERIT += "package_tar". Aug 18 14:16:01 Signed-off-by: Holger Hans Peter Freyther Aug 18 14:18:41 what is the recommended way to add custom configuration? some files in /etc needs to be tweaked for my needs Aug 18 14:20:39 ballon: it depends, one common way is to install machine specific files (e.g. see base-files) Aug 18 14:21:25 they're rather project specific than machine specific Aug 18 14:22:24 ballon: hehe, then provide more context. which files do you need to touch? are they coming from OE? or the upstream project? Aug 18 14:22:57 let me check Aug 18 14:24:28 chap-secrets, hcid.conf, local, options, pap-secrets and system.conf, all in /etc Aug 18 14:24:34 and fstab Aug 18 14:26:25 ballon: well, there is no generic answer... find the bb file that is installing the files, figure out if they are installed by OE Aug 18 14:26:48 ballon: if that is the case your machine/distro specific files (OVERRIDES), if we just copy the upstream... well then patch the source Aug 18 14:29:29 e.g. fstab comes from base-files, installed by OE, and this file is machine specific so create a subdir with ${YOUR_MACHINE}/fstab (you will that thsi already exists) Aug 18 14:29:33 Laibsch: I followed instructions from http://bugs.openembedded.net/show_bug.cgi?id=5246, it helps partially. The system boots to the end, but during creating MIME database there are failures 'no space on device'. Needs more investigation. Aug 18 14:34:21 jest: opie image? Aug 18 14:34:28 no, x11-image Aug 18 14:34:48 same problem? Aug 18 14:35:01 then we should see to commit a fix Aug 18 14:35:03 I'm not sure. At least the solution works :) Aug 18 14:35:32 I'll take a look at this issue tomorrow Aug 18 14:36:43 zecke: i see, the only thing i don't like with that approach is that the project specific files are under svn in a different directory than openembedded, and i'd rather keep all my changes and tweaks there than under the openembedded dir Aug 18 14:37:19 ballon: well, this is not how it works, bluez, base-files, etc. are not in the same repository either Aug 18 14:37:27 ballon: have you looked into bb collections? Aug 18 14:37:51 no, i've seen the expression but not more than that Aug 18 14:38:18 ballon: can you just SRC_URI them in to order based on some machine or ${your flag here} type setup. Aug 18 14:39:23 ballon: the idea would be, you can "fork" the bb files you touch in a tree structure like in OE, but put these into your SCM Aug 18 14:39:37 ballon: then you would have the different config files next to the bb file, in your svn Aug 18 14:40:05 is there a default way to install firmware binaries? Aug 18 14:40:23 Stecchino: check the linux-firmware recipe? Aug 18 14:40:37 zecke: correction, I haven't, but we are using a bb collection for the project. I'm just still not familiar with the terminology Aug 18 14:41:24 ballon: bb collections and a DEFAULT PREF = 99 can do wonders for these sort of hacks ;-) Aug 18 14:45:02 i'll do some more user manual reading tomorrow, the layout is still a bit confusing =) Aug 18 14:47:47 hi pH5 Aug 18 14:48:03 unfortunately some parts of it don't really say much at all Aug 18 14:48:50 thebohemian1: thanks for spotting the wrong week day Aug 18 14:48:54 ballon: some things take some working out but once you get your head around it things so seem to make sense ;-) Aug 18 14:50:22 DJWillis: usually that's the way it is, i've been doing linux stuff for over a decade. it's just the first couple of days with OE =P Aug 18 14:50:44 ballon: you might want to look into amend-recipes.inc, too. it'll let you override things in recipes, i.e. replace / remove config files Aug 18 14:51:53 msmith_: hey, your bash sites/ change didn't apply at x86_64-linux... did you add quagga support localy? Aug 18 14:52:09 msmith_: where do i find it? Aug 18 14:52:51 zecke: i think my reply hasn't made it to the list yet -- that patch is dependent on this one: http://patchwork.openembedded.org/patch/939/ Aug 18 14:53:03 ballon: http://article.gmane.org/gmane.comp.handhelds.openembedded/25159 Aug 18 14:53:34 thanks Aug 18 14:53:47 i'll check it out tomorrow, for now i'm out of here Aug 18 14:53:49 hi florian Aug 18 14:53:56 hi everyone except florian Aug 18 14:54:10 heh. Aug 18 14:56:12 msmith_: okay, I will have a look tomorrow morning Aug 18 14:56:29 msmith_: I would really love if you could write a page of documentation for grub and syslinux for the OE usermanual :) Aug 18 14:56:37 cool, thanks. Aug 18 14:56:48 Yeah I don't think there's anything on bootloaders at all. Aug 18 14:56:53 i'll have to take a look and see where it would fit Aug 18 14:58:21 msmith_: the Common Usage turns into a collection of usescases Aug 18 14:58:38 ok, i'll start there. Aug 18 16:44:38 03Sebastian Krzyszkowiak  07shr/import * r844962dbe0 10openembedded.git/recipes/shr/shr-theme-niebiee.bb: shr-theme-niebiee: add metapackage for Niebiee themes Aug 18 16:45:28 I have a bb collection in a separate dir with local patches to packages. but when they "require file.inc" they only look in the current dir and not the upstream dir, is there a way to fix this with variables or do I need to put "recipes/xxx/file.inc" everywhere? Aug 18 16:49:02 I think the var you are looking for is FILES_PATH Aug 18 16:49:13 Take a look at http://docs.openembedded.org Aug 18 16:49:22 It should be all documented there Aug 18 16:49:56 google: "inurl:docs.openembedded FILES_PATH" may be some help Aug 18 16:50:14 well I couldn't find anything for include/require files, only for SRC_URI files Aug 18 16:52:01 Oh, right Aug 18 16:52:24 If they all require the same file, why not put them in the same directory? Aug 18 16:52:30 They obviously share something Aug 18 16:52:52 because there is the original version in the openembedded git repo, and in my overlay there is the same file but with different patches Aug 18 16:53:26 so mine is in myrepo/recipes/linux/ and includes linux.inc, and the upstream is in oe/recipes/linux/linux.inc Aug 18 16:54:17 so when I have "require linux.inc" it doesn't find the one in the upstream repo, only if I have "require recipes/linux/linux.inc" Aug 18 16:55:01 I can just change it to use that format but I think I saw somewhere a workaround for this but I can't find it anymore.. Aug 18 16:55:20 I think kergoth would be your resource for that. Aug 18 16:55:53 ok, when/if he's active I'll ask again Aug 18 17:14:24 th1: you'd have to do the 'require recipes/linux/linux.inc' thing, since include/require only obey BBPATH, not FILESPATH, at least as things stand today Aug 18 17:15:30 could hack bitbake to make it a bit smarter about the include/require, checking the path to the FILE relative to its entry in BBPATH, and adding that subdir of each element in bbpath to the include searchpath.. but i really don't know if it'd be worth the effort Aug 18 17:20:55 kergoth, well it would be nice for the "collections" scenario, especially when I have files I am waiting to push upstream in a low-prio collection, that way I could diff the 2 and have the patch to send upstream :) Aug 18 17:21:03 but it is not a big deal, with the "path/to" it works fine Aug 18 17:21:23 yeah, i can see that. something to keep in mind for the future as a possible enhancement Aug 18 17:21:55 In my setup I have in fact 3 collections, one for local packages specific to my project, at highest priortiy, then the OE stock ones, as mid priority, and finally my "oe-addons" of my local fixes to OE Aug 18 17:23:30 nod, seems reasonable Aug 18 17:26:56 hmm, why OE fixes are at the lowest priority? Aug 18 18:06:52 Hi, Does it possible to setup mail server which makes some image processing by embedded system? Aug 18 18:16:06 awaad: wrong channel. This is for Open Embedded build system related discussions Aug 18 18:16:18 awaad: You might want to try a more generic channel Aug 18 18:17:36 rkirti: Sorry , I am new in the embedded system field, why my question is not related to the open embedded build system related discussions ?? Aug 18 18:18:31 awaad: I meant for support on issues while using the OE/bitbake platform Aug 18 18:19:42 rkirti : OK , can you advise me with some channel that can help me ? Aug 18 18:22:34 03Felix Domke  07org.openembedded.dreambox * r54062d5167 10openembedded.git/packages/enigma2/enigma2.bb: enigma2: workaround buggy extra_depends on split_packages Aug 18 18:24:27 rkirti : OK , can you advise me with some channel that can help me ? Aug 18 18:25:40 #edev? Aug 18 18:27:53 Crofton : This is what I am looking for , thanks alot Aug 18 18:28:50 what is the current way of adjusting FILESPATH? Aug 18 18:37:21 what is the difference between FILESPATH and FILESPATHPKG? Aug 18 18:43:44 03Stanislav Brabec  07org.openembedded.dev * rc019840b5f 10openembedded.git/recipes/xorg-lib/libxcalibrate_git.bb: libxcalibrate: Use increment-able PV format as other git version recipes do. Aug 18 18:43:45 03Stanislav Brabec  07org.openembedded.dev * rb38707cbe2 10openembedded.git/recipes/xorg-proto/calibrateproto_git.bb: calibrateproto: Use increment-able PV format as other git version recipes do. Aug 18 19:56:25 03Stanislav Brabec  07org.openembedded.dev * r2dcee26b6c 10openembedded.git/recipes/xorg-proto/calibrateproto_git.bb: calibrateproto: Added symlink to provide old package pkgconfig name. Aug 18 19:57:24 denix, "why oe fixes lowest priority" it's really "oe-addons" rather than fixes and when they get pushed upstream I want to use the OE version Aug 18 19:57:55 03Stanislav Brabec  07org.openembedded.dev * rbf2a35c513 10openembedded.git/recipes/ (tasks/task-mamona.bb xtscal/xtscal.inc): task-mamona.bb, xtscal.inc: DEPEND on libxcalibrate instead of xcalibrate. Aug 18 20:00:37 th1: ah, I see. I usually just remove things from my layer when they land in OE... Aug 18 20:01:56 03Stanislav Brabec  07org.openembedded.dev * r4064329427 10openembedded.git/recipes/xcalibrate/ (4 files in 2 dirs): xcalibrate: Removed old recipe replaced by libxcalibrate. Aug 18 20:01:57 03Stanislav Brabec  07org.openembedded.dev * ra007a699f5 10openembedded.git/recipes/xcalibrateext/xcalibrateext_git.bb: xcalibrateext: Removed old recipe replaced by calibrateproto. Aug 18 20:03:59 denix, I need to catch it automatically since lots of people will be working on the repo once it's in production Aug 18 20:04:38 of course my environment checks out a specific rev of the OE repo, and I bump it manually when sure it works and/or when something is broken that's been fixed upstream Aug 18 20:04:47 so I guess I could just remove it manually Aug 18 20:06:20 how do I set up a "slave build" to use packages off an earlier build when they are the right version (both for staging and image)? Aug 18 20:21:40 03Frederik Sdun  07shr/import * rc826ff7d0e 10openembedded.git/recipes/mokomaze/ (mokomaze-0.5.5/avoid_dim_suspend.patch mokomaze_0.5.5.bb): Aug 18 20:21:40 mokomaze 0.5.5 recipe Aug 18 20:21:40 Hi, Aug 18 20:21:40 I wrote a recipe for mokomaze 0.5.5. Aug 18 20:21:40 The Devs added some more levels designed by the community and a "pass-through-checkpoints" mode. Aug 18 20:21:41 diff of the recipe and the new patch attached Aug 18 20:21:45 regards, Frederik Aug 18 20:26:41 03Klaus Kurzmann  07shr/import * r027b6d82a0 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Aug 18 20:26:41 preferred-shr-versions.inc: update mokomaze to 0.5.5 Aug 18 20:26:41 Signed-off-by: Klaus Kurzmann Aug 18 20:29:38 th1: makes sense. I also keep snapshots of main OE repo, but I tend to keep it synchronized with my overlay Aug 18 20:39:15 re Aug 18 20:53:39 What should I put in PREFERRED_VERSION_connman if I want to build connman from connman_git.bb where is PV = "0.22+gitr${SRCPV}"? "0.22" or "0.22+git" or "git" doesn't work and bitbake -s shows only "0:0.22+gitr26+aac35324deb8c0b57f881338d87cb36b0979e7df-r1" which is not usefull for autorev, is it? Aug 18 21:29:06 JaMa: one way is to set DEFAULT_PREFERENCE higher than other competing recipes Aug 18 21:29:18 and do not use PREFERRED_VERSION Aug 18 21:47:10 khem: I hoped that it could be specified with some magic PREFERRED_VERSION without touching DEFAULT_PREFERENCE in perticular bbfiles.. at least to be able to build different distros with different PREFERED_VERSIONS on the same checkout of bbfiles... Aug 18 22:15:43 JaMa, maybe you can instead blacklist the newer version you don't want? Aug 18 22:20:02 khem, th1: thanks, I sort it out by using newest version in PV string and without DEFAULT_PREFERENCE = -1, sofar enough for me.. Aug 18 22:21:35 ok Aug 18 23:31:52 can I have an extra checksums file in an overlay? Aug 18 23:38:53 yes Aug 18 23:39:05 I forget who finally pushed that, but yaaaaay Aug 18 23:39:17 yay indeed :) Aug 18 23:39:21 you can just have an additions-only checksums.init in /conf/checksums.ini Aug 18 23:39:26 s/init/ini/ Aug 18 23:39:29 great Aug 18 23:40:03 so it will just concatenate all the checkums.init it finds? Aug 18 23:40:27 yay its working Aug 18 23:50:10 Has anyone else had a command fail when using bitbake, but it appears that the same command succeeds when run manually? Aug 18 23:51:20 yes, usually due to the env things that are setup as part of do_foo Aug 18 23:52:10 Ok... I think that's enough to get me started, thanks Aug 18 23:53:13 archae0pteryx, did you run the command from inside the devshell? Aug 18 23:53:26 concrete example with logs in pastebin will help narrowit down :) Aug 18 23:54:03 th1, I'm out of touch with how to use bitbake so I'm just trying to get back up to speed Aug 18 23:54:11 ok Aug 18 23:54:20 It looks like --environment and --interactive is what I need, is that correct? Aug 18 23:54:32 well -D -D will do in a pinch ;) Aug 18 23:54:40 then you need bitbake -c devshell Aug 18 23:54:49 but for devshell to work you need to add itto your local.conf Aug 18 23:55:27 devshell basically opens a shell after do_patch with all env set as if it was about to do do_compuile Aug 18 23:57:01 http://wiki.openembedded.net/index.php/Devshell or http://docs.openembedded.org/usermanual/html/usage_devshell.html Aug 18 23:57:49 Ok, too bad this isn't with the official bitbake documentation Aug 18 23:57:58 the second link is from the official documentation Aug 18 23:58:31 not that the docs couldn't use a facelift but they aren't that bad Aug 18 23:59:03 Eh, just looks I need to RTFM :P Aug 18 23:59:11 ;) Aug 18 23:59:48 I was looking at some minimalist bitbake documentation which basically said these are the different protocols supported and here is a list of the options Aug 19 00:00:00 well Aug 19 00:01:34 *shrugs* If I RTFM and still get stuck then I will come harass again but not before ;) Happy just to be able to get started again Aug 19 00:03:33 you need to read the openembedded manual Aug 19 00:03:35 sorry Aug 19 00:03:40 laptop ran out of battery ;) Aug 19 00:03:53 the wiki is also good Aug 19 00:04:16 the OE manual is the main thing to read, bitbake manual, ok , skim it but don't worry too much about it before you want to do advanced stuff ;) Aug 19 00:05:01 I think it would be good to add the few bits of bitbake info that are really necessary to the OE manual itself Aug 19 00:05:22 Yeah well, I used OE from, oh, maybe a year ago for a long while and I haven't been doing anything at all with it for about half a year Aug 19 00:05:32 or alternatively have a "readers digest" version of bitbake manual for OE users :) Aug 19 00:05:35 Obviously lots of changes Aug 19 00:05:45 hehe Aug 19 00:05:46 Yeah readers digest would be nice ;) I'm very impatient Aug 19 00:05:57 I've never used it before, started a week ago, and I'm integrating it to a major project Aug 19 00:06:08 so I've had my work cut out the last week or so Aug 19 00:06:32 I keep getting distracted because I have a lot of maintenance to do and its hard to sit down and concentrate Aug 19 00:06:49 like, the "collections" page of the OE manual. I needed it, but the manual chapter was just "TBD" and an example :) Aug 19 00:07:16 I know I get the same thing Aug 19 00:07:23 we are all to busy doing cool shit Aug 19 00:07:27 hehe :) Aug 19 00:07:38 and (at least in my case) I suck at writing Aug 19 00:07:58 I'm ok if I spend hours editing what I write ;P Aug 19 00:08:05 well, we have a doc writer in our project maybe when he gets some spare cycles he can write on it;) Aug 19 00:08:35 but tbh, OE is by far the best of a bad bunch Aug 19 00:08:39 that would be awesome! Aug 19 00:08:54 we would really like to attract people who want to do docs Aug 19 00:08:57 well Aug 19 00:09:04 I have an internal wiki, maybe sometimes it wouldn't be hard to copy-paste Aug 19 00:09:35 one of our company goals is contribute back to open source Aug 19 00:09:44 awesome Aug 19 00:09:49 its part of the bonus if you do, so people are fairly motivated ;) Aug 19 00:10:39 right now I'm just struggling to get OE working as well as buildroot for the project, to convince the team to make the switch Aug 19 00:10:51 if they do I'm sure we'll contribute a fair amount to OE Aug 19 00:11:29 but it's quite a different use case to the normal applications of OE... Aug 19 00:11:34 buildroot is ok, until things get complicated, well that is my impression Aug 19 00:11:47 mine too, that's why I'm pushing for OE Aug 19 00:11:47 I need to go eat Aug 19 00:11:52 ok Aug 19 00:11:58 but I'd like to know what you are thinking Aug 19 00:12:07 frakking starving :) Aug 19 00:12:11 well it's 1am here so probably tomorrow then :) Aug 19 00:12:17 urg Aug 19 00:12:19 yeah Aug 19 00:12:23 8PM here Aug 19 00:12:32 anyhow I work for Citrix (Xen) Aug 19 00:12:36 We never did buildroot Aug 19 00:12:42 I may not be around in my AM, need to ride my bike Aug 19 00:12:49 th1 my SO is writing the book on Xen :) Aug 19 00:12:52 interesting Aug 19 00:12:59 definitiley a different use case Aug 19 00:13:02 well, a book Aug 19 00:13:22 we're doing a laptop/desktop hypervisor and we need rootfs for dom0 and a management vm Aug 19 00:13:29 that's where OE/buildroot comes in Aug 19 00:13:44 Interesting Aug 19 00:14:15 So you know xen really well? Aug 19 00:14:19 well Aug 19 00:14:31 I know it reasonably well :) I'm fairly new in this job Aug 19 00:15:25 but I sit next to some of the guys who wrote xen Aug 19 00:15:39 That's cool Aug 19 00:15:50 They wrote the book on xen too ;) Aug 19 00:16:04 There's not actually that many it seems Aug 19 00:16:15 well the main guy is Keir Fraser Aug 19 00:16:33 he knows it pretty much inside out ;) Aug 19 00:17:13 LOL well yeah, does he approve all the changes? Aug 19 00:17:24 just for the hypervisor Aug 19 00:17:36 like linus for his kernel ;) Aug 19 00:17:44 Yeah, that's what I was thinking about Aug 19 00:18:16 I think Linus delegates most stuff these days Aug 19 00:18:30 Seems like it. Just too much Aug 19 00:18:33 yeah Aug 19 00:18:57 but this xenclient we're doing is open source as well Aug 19 00:19:04 including the stuff I want to use OE for Aug 19 00:19:18 http://xenbits.xensource.com/xenclient/ Aug 19 00:19:26 Well, I'm curious to see it when it's out, will you push the stuff for xen into OE? Aug 19 00:19:29 the public repos lag a week or so but that's it Aug 19 00:19:38 well Aug 19 00:20:02 what I've done is set up a repo with OE overlays and scripts that build the whole thing Aug 19 00:20:22 so our overlays have the xenclient specific bits Aug 19 00:20:46 but whatever fixes and additions we make to OE will be pushed upstream Aug 19 00:20:52 cool Aug 19 00:21:49 it'll be a new area for OE Aug 19 00:22:49 Well, I need to dig myself into a hole and read the RTFM, catch you later th1 Aug 19 00:22:49 buildroot just lacks the scalability imho. package based builds is the way forward Aug 19 00:22:56 ok later :) **** ENDING LOGGING AT Wed Aug 19 02:59:56 2009