**** BEGIN LOGGING AT Mon Sep 12 02:59:57 2011 Sep 12 06:16:52 hi ericben Sep 12 07:52:11 good morning Sep 12 08:44:52 hi all, does anyone know a working oe-core sources mirror? Sep 12 08:46:07 mr_nice: poky is using autobuilder.yoctoproject.org/sources/ Sep 12 08:47:34 yes but it is down ;) Sep 12 10:13:53 I do not succeed in specifying BBFILES as an environment variable instead of putting it in local.conf. Is that possible? Sep 12 10:36:38 Can I specify BBFILES in my .profile? Sep 12 10:41:14 kobe: if you want to be able to specify it from the environment you need to add it to BB_ENV_EXTRAWHITE Sep 12 10:41:32 (BB_ENV_EXTRAWHITE is set by the environment script) Sep 12 10:44:22 Thanks. I Sep 12 10:44:29 Thanks. I'll look into that. Sep 12 14:37:48 Hello ... Sep 12 14:38:01 did someone see my mail about using different prefix then /usr? Sep 12 14:39:23 I saw it, but I don't have any commments ... Sep 12 14:39:37 largely because I am an idiot about these things :) Sep 12 14:43:32 Crofton: nice that I am not alone on this idiotness ;-) Sep 12 14:43:46 Crofton: I also feel lost about it ;-) Sep 12 14:51:57 otavio: from past patches it kind of sounds like pb_ may have some experience in this area Sep 12 14:53:31 pb_: :-D Sep 12 14:53:41 pb_: mind to talk a little about this issue? Sep 12 14:53:53 bluelightning: thx Sep 12 15:03:42 sorry, which issue is this? Sep 12 15:08:32 otavio: ^ Sep 12 15:10:11 pb_: I am trying to build a rootfs but to use a prefix different of /usr but /opt/foo Sep 12 15:10:58 pb_: most packages built except e2fsprogs and xserver-xorg however I think both issues are the same. So if you might take a look on the e2fsprogs issue I might be able to fix xserver-xorg later, myself Sep 12 15:11:13 what is the failure you see with e2fsprogs? Sep 12 15:11:36 pb_: it fails to link with libuuid Sep 12 15:12:08 hm. well, it works for me with prefix="" Sep 12 15:12:32 pb_: yes Sep 12 15:12:44 pb_: it ought to work to /opt/foo too IMO Sep 12 15:13:12 pb_: but it fails. Is it possible for you to give it a try and see if you have a clue? Sep 12 15:13:30 pb_: I am trying to fix it since Saturday :( Sep 12 15:13:42 though, looking at the logs, it doesn't seem that my recipe is linking against libuuid at all. Sep 12 15:13:53 you're using the current head of oe-core, right? Sep 12 15:13:57 pb_: have you disabled libblkid? Sep 12 15:13:59 pb_: yes Sep 12 15:14:16 pb_: in e2fsprogs? if I do, then it builds Sep 12 15:14:18 not that I recall. afaik, I'm just using the out-of-the-box configuration Sep 12 15:14:22 let me check though Sep 12 15:14:46 pb_: xserver-xorg, at other side, fails to link with libGL Sep 12 15:15:27 I don't seem to have any local changes to e2fsprogs in my tree. Sep 12 15:15:42 if you want to mail me your log.do_compile and log.do_configure then I can probably take a look at them. Sep 12 15:15:55 I don't really have the time to set up a tree to do a whole build with a different prefix right now. Sep 12 15:26:59 pb_: OK; to where I should mail the logs? Sep 12 15:32:31 philb@gnu.org Sep 12 15:46:39 pb_: done Sep 12 18:11:02 pb_, ping? Sep 12 18:13:11 khem, ping Sep 12 18:14:59 hi Sep 12 18:18:30 morning Sep 12 18:26:34 XorA, g'day Sep 12 18:26:45 headed up there wednesday. Sep 12 18:30:12 Ill be on plane home weds :-( Sep 12 18:30:18 Ill catch you next time Im in CA Sep 12 18:37:53 sorry... Sep 12 18:38:04 too many problems locally ;( Sep 12 18:46:25 is there a way to use tags instead of sha's for git sources? Sep 12 18:49:12 pb_: did you have a look at the logs? Sep 12 18:51:25 msm, yes, but it's ill-advised since a tag causes a network access Sep 12 18:51:54 norm is # This is the SHA for vWhatever-tag above Sep 12 18:56:26 ah, ok Sep 12 19:02:45 msm: take a look on gitpkgv class in meta-oe Sep 12 19:02:50 msm: it does what you want Sep 12 19:03:42 otavio: ok, thanks Sep 12 19:03:45 ka6sox: Well if you ever come .eu ways we can also attempt to beer Sep 12 19:04:25 msm: I added SRCREV_FORMAT support to gitpkgv so now you can even use more then one git repository to assembly the source and the version Sep 12 19:04:29 msm: it works like a charm Sep 12 19:04:54 hmm interesting… Sep 12 19:05:02 msm: yes Sep 12 19:06:13 XorA, will do. Sep 12 19:29:43 otavio: thought about pulling over an equivalent to the TAGADJUST variable from gitver into gitpkgv? there are more useful adjustments you can make to the tagging than just the 'v' prefix (e.g. use of _ for separators rather than ., particularly for conversions from cvs/svn) Sep 12 19:30:23 kergoth__: I did not Sep 12 19:30:36 I think it'd be a useful addition Sep 12 19:30:46 kergoth__: in fact gitpkgv has worked fine for my current need but it doesn't scale to my next needs Sep 12 19:31:32 kergoth__: i've been thinking about a way to put static library versioning inside of PKGV and PV users so the users will be rebuild every time the static library is updated Sep 12 19:32:18 might be easier to just use the basichash stamp handler and let everything rebuild when deps signatures change Sep 12 19:32:49 kergoth__: where I find information about it? Sep 12 19:32:53 I wrote something once that implemented explicit abi versioning, and the abi versions of your deps got captured, so if the dep abi changed, you'd get rebuilt, but I doubt it'd be useful nowadays Sep 12 19:33:05 otavio: not much to read about it, it just makes it so the signature is in the stamp files Sep 12 19:33:17 iirc its just BB_SIGNATURE_HANDLER = "basichash" or similar Sep 12 19:33:45 kergoth__: but the binary revision won't change Sep 12 19:34:02 kergoth__: so for public packages this won't work, will it? Sep 12 19:35:25 you're talking about cases where a static library from a recipe is changed without the signature for that recipe changing? hmmm Sep 12 19:35:54 kergoth__: I meant pkgA uses libpkgB Sep 12 19:36:02 kergoth__: and libpkgB changes Sep 12 19:36:32 kergoth__: so pkgA needs to be updated to be rebuild and this needs to be also done in PV otherwise update won't work Sep 12 19:36:46 kergoth__: PV or PR Sep 12 19:36:54 if you use basichash, if A deps on B, and B's signature changes, A will get rebuilt Sep 12 19:37:22 kergoth__: but PV-PR won't be change, will it change? Sep 12 19:37:53 ah, I see, you want the rebuilt package to show up as an upgrade in the feed.. hmmm Sep 12 19:38:03 kergoth__: yes; of course :-D Sep 12 19:38:09 * kergoth__ ponders Sep 12 19:41:20 wouldn't it perhaps be easier to remove the entire PR handling from the metadata, and see that as a seperate problem specific to managing package feeds from builds Sep 12 19:41:55 it would certainly simplify matters Sep 12 19:42:30 Esbenh: basically if the recipe of stamp changes, rebuild? Sep 12 19:42:44 at any point in time, after (re)building some stuff, you can check which packages that has been rebuilt relative to what is in the feed, and why they have been rebuilt Sep 12 19:43:40 the package feed maintainer should then be able to decide whether the changes are to be considered no-op, or if the new packages should be placed in the feed, in which case the "PR" of the package in the feed would be updated. Sep 12 19:44:26 Esbenh: I'd prefer if they go to feed and get PR bumped automatically Sep 12 19:44:28 otavio: if the signature of the recipe (including recursively the signature of all dependencies) changes, the recipe is rebuilt Sep 12 19:44:40 Esbenh: otherwise it is too easy to get it wrong Sep 12 19:45:33 otavio: and that would be the easiest way to manage the feed, but if someone fancy playing smarter than that, fx. to save bandwidth for updates, it would probably be wise to have the infrastructure in place to handle that also Sep 12 19:46:31 if fx. you fix a very specific bug in autoconf-native, you might not want to have all recipes depending on that updated in your feeds.... but that specific package that had the bug, that the autoconf-native updated fixes, should be updated. Sep 12 19:47:41 the strength of the current PR management method is that you naturally limit the feed updates to those Sep 12 19:48:01 the downside, ofcourse being that PR bumps are forgotten almost as often as they are done Sep 12 19:48:57 this is the very sketchy plan I have for (re)adding package feed support to OE-lite. Sep 12 20:52:53 is there an easy way to modify ASSUME_PROVIDED per host distro? Sep 12 21:04:28 msm, not without adding depends on more host utils to do so, and also taking that risk Sep 12 21:04:42 (the risk of using someone elses tools) Sep 12 21:08:50 Tartarus, can I make a pull request from github for the release branch? Sep 12 21:09:06 yes Sep 12 21:09:10 ok Sep 12 21:09:15 I need to get one together Sep 12 21:09:30 I have some changes I need, and some F16 stuff queued up Sep 12 21:12:51 Tartarus: what about setting ASSUME_PROVIDED in the developers environment? Sep 12 21:12:56 or something to speed things up for developers? Sep 12 21:13:11 you only build the native suff once Sep 12 21:13:46 I know, but developers only build the thing once ever then their recipe is working and they are done Sep 12 21:14:22 but I agree it's mostly unmaintainable to depend on host distro stuff Sep 12 21:15:11 msm, yes, that's one of the things sstate is to help with Sep 12 21:15:26 once you build it once you can share, so long as the env stays sane Sep 12 21:15:30 and you can reuse it yourself alot Sep 12 21:15:39 yes, i do as well Sep 12 21:33:52 msm: I've used something similar to https://gist.github.com/869616 for myself. I wouldn't make it anything but for personal use though, since you can never be sure that a given item added to assume provided won't break something.. Sep 12 21:33:53 heh Sep 12 21:37:22 ah, interesting Sep 12 22:41:10 as i try bitbake, and notice that its fetch method is error prone... Sep 12 22:41:20 why has nobody ever made that auto-re-get on error? Sep 12 22:42:02 more interesting question is HOW is it error prone while using TCP! Sep 12 22:46:23 it downloads from remote servers. obviously, those servers aren't under our control. they're free to remove the files we depend upon. Sep 12 22:46:33 and "auto-re-get"ing in that context won't do a damn thing Sep 12 22:47:26 it failed on getting linux. Sep 12 22:47:36 i removed the failed file and re-ran, and it worked fine Sep 12 22:48:11 all well and good once you LEARN that you have to do that manually Sep 12 22:49:43 kernel.org was down for a hell of a long time. Sep 12 22:49:52 again, regetting while the server was down would have done absolutely nothing Sep 12 22:50:28 this was a virgin run today Sep 12 22:50:34 as in the past hour Sep 12 22:52:08 so the rule is if checksum mismatch error, blow away the offending file in the source dir? is this correct? Sep 12 22:53:15 a lot of wget wlll fetch a file from these servers, but then they are not present so you get a default 404 page… it does not know this is the wrong file until you do the md5 Sep 12 22:53:20 well, don't know what to tell you. once again, kernel.org isn't within our control. if it hands us crap, are we supposed to magically know *why* that was the case? redownloading doesn't guarantee a fix. there have been plenty of occasions where the file on the server was modified by someone else. Sep 12 22:53:32 i guess if the md5 fails it should delete and try a different mirror Sep 12 22:53:58 if we did that, it could end up wasting hours downloading the same file over and over again. i guess you could opt into it, but i really don't see the point, personally Sep 12 22:54:09 well, a different mirror at least Sep 12 22:54:26 esp. for times like now, when all these web servers are down Sep 12 22:54:37 i think i am starting to see the problem Sep 12 22:54:43 well understand it Sep 12 22:55:02 you're starting to see the edges, the shape of the problem. we've barely even covered a portion of the possible cases to consider Sep 12 22:55:10 to be noob friendly the error message would need to present some clues as to what to do next other than cry and give up Sep 12 22:55:58 Personally, I'd rather things fail and let me handle it than try to magically fix it or *guess* about a possible cause, of which there can be many.. Sep 12 22:56:40 first time i got the checksum, i manually changed all checksums. that got past teh problem but was utterly the wrong thing to do. not knowing that the wget failed Sep 12 22:58:43 and again, you don't *know* what the right thing to do *is* when encountering a checksum mismatch until you investigate. Sep 12 22:59:13 i am trying to learn. are their any good hint pages? Sep 12 22:59:36 i am a couple months of trying off and on, with no successes under my belt yet Sep 12 23:35:34 is correcting a checksum something that one ever does to a bitbake recipee? say for something like binutils 2.20.1? Sep 12 23:37:33 I saw a patch for that drift past email list a few days ago, sometimes people do check in mistakes, or the upstream does change the release packages Sep 12 23:37:57 i think i am going to have to get on that mail list Sep 12 23:38:18 monitoring it might help me find success, mind giving me a pointer to the signup page? Sep 12 23:38:44 googling now Sep 12 23:39:11 do you remember which list had that/ Sep 12 23:41:17 cool. found the email you reference. i made the same fix Sep 12 23:41:48 xora thanks :) Sep 12 23:42:37 no probs, the only email I think I have read in 2 weeks Sep 12 23:42:52 heh Sep 12 23:43:05 my plan is to get the bitbake build to work Sep 12 23:43:24 then i can hopefully start learning how to modify it, so as to insert compilers and other useful kit Sep 12 23:48:48 the environment you run the build in matters right? ubuntu 10 not ubuntu 11 Sep 12 23:49:49 Ubuntu 11.04 should be fine Sep 12 23:51:02 you have done successful builds on 11.04 with OE and bitbake? Sep 12 23:51:43 yes Sep 12 23:52:06 Debian Squeeze as well Sep 12 23:52:17 ok, cool. i had read somewhere it had issues. stupid voodoo posts Sep 12 23:55:16 Natty was broken for a few days after its release but that problem has been fixed for some time now Sep 12 23:56:21 i am starting to get a better feeling about getting this to work. that usually indicates an on coming train **** ENDING LOGGING AT Tue Sep 13 01:52:38 2011 **** BEGIN LOGGING AT Tue Sep 13 19:40:14 2011 Sep 13 19:44:45 stefan_schmidt: yup Sep 13 19:47:15 JaMa: heh, just this second I found my problem :) Sep 13 19:47:19 JaMa: right timing :) Sep 13 19:47:27 JaMa: was about touchscreen with X Sep 13 19:47:43 JaMa: I had some trouble with tslib vs. evdev Sep 13 19:48:16 But its sorted out now. evdev works as it should now as does xinput_calibrate_once.sh Sep 13 19:48:40 JaMa: Just one question. SwapAxes is no longer needed with evdev? Sep 13 19:49:06 stefan_schmidt: you can swap axes with xinput (xinput-calibrator) Sep 13 19:49:35 JaMa: is it preferred over the xorg.conf option? Or does it not matter? Sep 13 19:49:51 hi GNUtoo Sep 13 19:50:00 hi Sep 13 19:50:22 stefan_schmidt, when will buglabs migrate to oe-core? Sep 13 19:51:10 GNUtoo: we are switching to angstrom 2010 here Buglabs in the 2011.03 and your -fPIC fixes for our JNI stuff helped me. :) Sep 13 19:51:24 GNUtoo: (oe-core) You always want more :) Sep 13 19:52:02 GNUtoo: Its all a bit slower with a released product. Angstrom 2010 and e17 for now. The next major release will hopefully go with oe-core Sep 13 19:52:17 stefan_schmidt: I prefer both (calibration + swap) in pointercal.xinput Sep 13 19:52:23 Which will hopefully have a release (and and angstrom release on top) until then Sep 13 19:52:38 JaMa: ok, sounds good Sep 13 19:53:46 stefan_schmidt: btw otavio found some issues with xorg patch which makes xinput calibration working.. Sep 13 19:54:03 ok nice Sep 13 19:54:16 JaMa: IIRC that's with oe-core, right? Still on 2011.03 here. Sep 13 19:54:50 I know I know. But I just do this part time and won't rush into oe-core with a released product :) Sep 13 19:55:00 stefan_schmidt: meta-oe, only because oe-core doesn't have that patch yet Sep 13 19:55:23 JaMa: err, sure. I meant that meta-oe Sep 13 19:55:25 ok Sep 13 19:55:26 since I'm currently working for eukrea, I've less time...but as soon as I get more time I'll come back playing with the bug 2.0 Sep 13 19:55:27 also the freerunner needs some love for shr-core Sep 13 19:55:28 next major release means a new device? Sep 13 19:55:29 I hope the old one will still be supported Sep 13 19:55:30 (bug 2.0 beeing the old one) Sep 13 19:55:40 stefan_schmidt: but same patch is in oe.dev xserver.. Sep 13 19:56:24 GNUtoo: no new device I know about. But timeline for the next major release isn't decided either. Sep 13 19:56:58 ok Sep 13 19:57:01 JaMa: ah, good to know. xinput calibration works here though Sep 13 19:57:11 the 2.0 is already so great.... Sep 13 19:57:55 stefan_schmidt: his issues are triggered by resolution change with xrandr Sep 13 19:58:10 stefan_schmidt: and patch is solving wrong calibration after rotation with xrandr :) Sep 13 19:58:23 GNUtoo: read the ford + buglabs news today? Sep 13 19:59:02 JaMa: ok, no xrandr here. That's why I did not see it. But that's good to keep in mind Sep 13 20:05:41 2 more days until NeTV will be released Sep 13 20:06:31 ah it seem that the car would run both Sep 13 20:08:36 I'll go bye Sep 13 20:10:06 hi GNUtoo Sep 13 20:18:09 enough for now. CU Sep 13 20:32:53 is there an easy way to clean out of date scache? Sep 13 20:41:17 sstate-cach? rm -fr build/sstate-cache Sep 13 20:42:33 hi kergoth Sep 13 20:48:21 03Joshua Lock  07master * r09f5aed2ed 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: Sep 13 20:48:21 ui/crumbs/hobeventhandler: fix test for BBFILES Sep 13 20:48:21 It seems we have a race whereby the image_dir variable may not be set Sep 13 20:48:21 before it's tested for, since the variable is always the same set it in the Sep 13 20:48:21 initialiser. Sep 13 20:48:22 Partially addresses [YOCTO #1468] Sep 13 20:48:22 Signed-off-by: Joshua Lock Sep 13 20:48:31 03Joshua Lock  07master * r4394e38b03 10bitbake.git/lib/bb/ui/hob.py: Sep 13 20:48:31 hob: correctly handle an exception Sep 13 20:48:31 It doesn't matter if we can't remove the temprorary file, for some reason, Sep 13 20:48:31 so catch the exception and ignore it. Sep 13 20:48:32 Partially addresses [YOCTO #1468] Sep 13 20:48:32 Signed-off-by: Joshua Lock Sep 13 20:48:33 03Joshua Lock  07master * r39ed18e70e 10bitbake.git/lib/bb/ui/crumbs/hobeventhandler.py: Sep 13 20:48:33 ui/crumbs/hobeventhandler: don't check BBPATH and BBFILES each build Sep 13 20:48:34 There's no need to check the BBPATH and BBFILES are set correctly each Sep 13 20:48:34 build when running multiple builds for one launch of the UI. Sep 13 20:48:35 Partially addresses [YOCTO #1468] Sep 13 20:48:35 Signed-off-by: Joshua Lock Sep 13 20:48:36 03Joshua Lock  07master * rf4be83aae7 10bitbake.git/lib/bb/ui/hob.py: Sep 13 20:48:43 hob: correctly set the selected image when loading a recipe Sep 13 20:48:43 When the user saves their recipe based on an existing image type, loads it Sep 13 20:48:43 in a newly run hob instance and clicks bake they should not be asked about Sep 13 20:48:43 building packages vs an empty image up. Sep 13 20:48:44 Partially addresses [YOCTO #1468] Sep 13 20:48:44 Signed-off-by: Joshua Lock Sep 13 21:10:58 hi joelagnel Sep 13 21:11:52 hey Sep 13 22:31:38 hi. can anyone help me with a problem with recipe writing? Sep 13 22:34:28 darkopium: If nobody can please write to the list. Sep 13 22:34:44 And just post the question. You will see if someone will be able to help you. Sep 13 22:34:54 … or has the time to help you. Sep 13 22:35:19 oh ok, fair enough,.. Sep 13 22:52:35 darkopium: »post« included also this channel. ;-) Sep 13 22:52:52 I hope somebody is still awake to help you. Sep 13 22:52:59 Good night. Sep 13 23:11:41 I'm trying to write a recipe to build a package for my application. The application is pretty basic in that it is just a make file. I have it compiling, and copying files to the ${D}${bindir} and ${D}${libdir} Sep 13 23:12:15 But the problem is the ipk that is generated doesn't include any files from these directories, and I don't know why. Sep 13 23:14:51 i do believe this will work if the filesystem can re-size Sep 13 23:25:59 Sorry I don't know what you mean. Sep 13 23:26:43 darkopium: if files are installed to that path in do_install, they should end up in the main package, unless you've overridden FILES_${PN}. Sep 13 23:28:09 I had tried without overriding FILES_${PN} before, but I will give it another go. I had since overridden FILES_${PN} with "FILES_${PN} = "${bindir}/* \ ${libdir}/*" Sep 13 23:30:20 the default value already includes the binaries and *.so.* in libdir. *.so is in -dev, as it's generally a symlink only used for build time linking Sep 13 23:30:24 see conf/bitbake.conf Sep 13 23:32:00 oh ok, so it is safe to just remove my overridden FILES_${PN} variable? Sep 13 23:33:48 oh i see, how about if my libraries sit under ${D}${libdir} such as ${D}${libdir}/mylibs ? Sep 13 23:41:46 then you'd have to add that to the files variable Sep 13 23:41:53 FILES_${PN} += "${libdir}/mylib" Sep 13 23:43:04 okay thanks I will give that a go. But it will puzzles me why my binary files located at ${D}${bindir} wasn't being included, maybe I'll remove it from the override and hope for the best Sep 14 00:09:06 http://pastebin.com/tEhh6hdN Sep 14 00:09:21 just saw this building a 3.0 based kernel on the maintenance bracnh Sep 14 00:09:33 | kernel/module.c:3353:1: internal compiler error: in arm_unwind_emit, at config/arm/arm.c:22672 Sep 14 00:09:36 HELP! Sep 14 00:09:38 :) Sep 14 00:21:46 kergoth: thanks for the tip. the files are now appearing in the package files, but not appearing when i build an image, ie. image-console. Sep 14 00:22:36 darkopium: that would be because you didn't add the package to an image, no doubt Sep 14 00:22:37 how do i add the package to the image build? i modified (for now) the distro conf file by adding my package to the DISTRO_EXTRA_RDEPENDS, but that didn't work Sep 14 00:23:14 should i be modifying the image recipe, or the distro conf file? Sep 14 00:24:04 I tend to write my own image recipe Sep 14 00:26:13 housel: so my additional packages should go into the image recipe? I intend to write my own recipe, but would like to get it working first so I know how to write the recipe :) Sep 14 00:27:01 Yes, that's what I normally do Sep 14 00:27:45 Would I add my package to the IMAGE_INSTALL variable? Sep 14 00:28:30 yep Sep 14 00:29:05 You may need to the enclosing recipe to DEPENDS too Sep 14 00:29:20 oh so both variables Sep 14 00:30:18 thanks guys, will give it a go Sep 14 00:30:23 For instance I have both 'DEPENDS += "linux-firmware"' and 'IMAGE_INSTALL += "linux-firmware-rt2x00"' Sep 14 00:31:01 oh ok. how come there is an additional suffix in the IMAGE_INSTALL variable? Sep 14 00:32:37 The recipe generates multiple packages Sep 14 00:33:29 So if my package is called "mypackage" and it only generates one package, I would add mypackage to both variables? Sep 14 00:33:34 Yes Sep 14 00:34:29 Okay, thanks heaps. I had been stuck on this for a while. Sep 14 00:34:42 It is appearing in the image build now. :) Sep 14 00:34:58 alternatively, particularly for testing: echo "IMAGE_INSTALL_append = ' foo'" >> conf/local.conf **** ENDING LOGGING AT Wed Sep 14 02:59:57 2011