**** BEGIN LOGGING AT Wed Feb 08 02:59:57 2012 Feb 08 04:00:28 I guess git.shr-project.org is offline Feb 08 04:00:33 is that on purpose? Feb 08 04:14:03 damnit, i hate when i send something to the wrong list Feb 08 04:18:46 kergoth, I thougth only I did that. Feb 08 04:18:58 :) Feb 08 04:21:16 speaking of which...i need to send one... Feb 08 05:49:22 is there an easy way to remove alsa from COMBINED_FEATURES ? Feb 08 07:04:31 gm Feb 08 09:07:24 good morning Feb 08 09:51:07 how do you set preffered provider of virtual/kernel? I tried sett PREFFERED_PROVIDER_virtual/kernel ?= "my-kernel" in the conf file for angstrom. Is this the correct approach, or should it be set in local.conf? Feb 08 09:54:42 morning all Feb 08 09:54:47 mornin Feb 08 09:54:57 mertsas: you probably want = rather than ?= Feb 08 09:55:06 mertsas: ?= only sets if not already set Feb 08 10:01:43 good morning Feb 08 10:03:22 hi florian, bluelightning, all Feb 08 10:03:34 hi pb_, florian Feb 08 10:15:17 gm Feb 08 10:15:29 hey likewise Feb 08 10:15:55 hi Jin^eLD, likewise Feb 08 10:16:36 I have a recipe that uses srctree.bbclass, which inherits clean, but fails with: ERROR: Could not inherit file classes/clean.bbclass Feb 08 10:16:46 this is with oe-core and meta-oe. Feb 08 10:17:22 likewise: even with clean.bbclass it will fail because it needs few tweeks to work with sstate Feb 08 10:17:52 JaMa: yes, it seems clean.bbclass is no longer with us. Maybe I should not use srctree? Feb 08 10:18:00 likewise: http://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/test&id=5c3503d76cb6114b825bb34692ab29cfbcd4f310 Feb 08 10:18:17 yes it's not really usable now Feb 08 10:19:14 JaMa: thanks for looking at this. What is the best way to work with source-in-meta recipes and sstate? Feb 08 10:19:54 JaMa: did you mean your commit already has the "tweaks" applied for sstate, or that it still needs tweaks? Feb 08 10:20:23 no with this you will get srctree failing not because of missing clean.bbclass but like this http://paste.pocoo.org/show/547701/ Feb 08 10:20:52 and I haven't found time to fix it to work correctly yet Feb 08 10:20:56 feel free to do it Feb 08 10:22:46 or ping kergoth if he hasn't updated version for oe-core Feb 08 10:23:17 likewise: you don't necessarily need srctree, you might be able to just set ${S} appropriately. Feb 08 10:23:55 by the by, how to get commit access to meta-openembedded-contrib? I have some gprs-gps-tracker recipes boiling Feb 08 10:24:07 the only real technology in srctree is to cope with multiclassed recipes. if yours isn't one of those then you don't need it. Feb 08 10:26:41 does sources.openembedded.org have to be added manually or is it standard? Feb 08 10:27:51 pb_: thanks. these are indeed simple test tools I would like to keep in-meta Feb 08 10:28:24 ka6sox: I think khem submitted a patch to add both OE and Yocto mirrors, just the other day Feb 08 10:28:40 good Feb 08 10:28:58 because klibc-1.5.25.tar.bz2 isn't found at the kernel.org mirror they are specifying Feb 08 10:29:01 ka6sox: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/mirrors.bbclass Feb 08 10:29:04 I can get to from another mirror. Feb 08 10:29:12 and put it in ours. Feb 08 10:30:02 ka6sox: I wrote a tool to google for a package based on the MD5 sum, that I use when I package is not fetchable. Feb 08 10:30:16 ka6sox: but having mirrors is best Feb 08 10:30:47 thanks, Feb 08 10:31:12 I should check the md5sum before i fetch it and put it in our mirror. Feb 08 10:32:04 pb_: in your proposed approach, will the package built inside the source dir, or copy to the workdir firsT? Feb 08 10:32:12 built=>build Feb 08 10:35:17 depends on the build system. if it would normally compile inside ${S} then that's what will happen (though you can make a forest of hardlinks inside ${TMPDIR} and build there if you want. Feb 08 10:41:59 okay, 3am here, either someone else can submit a patch or when I am more awake I can put it in our repo. Feb 08 10:43:03 its here: http://ftp.osuosl.org/pub/linux/libs/klibc/1.5/ Feb 08 10:43:39 klibc-1.5.25.* Feb 08 10:47:43 ka6sox: who has access to the repo? Feb 08 10:47:53 ka6sox: can khem add this? Feb 08 10:48:18 ka6sox: anyway, good nite if you still are going to zzz Feb 08 10:56:08 bluelightning: thanks, but PREFFERED_PROVIDER_virtual/kernel is the correct variable as well? Feb 08 10:56:18 mertsas: yes Feb 08 10:58:59 well, not quite. fewer Fs and more Rs. Feb 08 10:59:34 :-) Feb 08 11:14:55 florian: hi Feb 08 11:15:02 florian: got emacs running^^ Feb 08 11:15:06 mertsas: ah yes, ensure you spell PREFERRED correctly Feb 08 11:23:04 maybe be should grep for PREFERE, PREFFE and fail :) Feb 08 11:31:17 bluelightning: yeah, that shit happens. I'll double check my spelling Feb 08 11:41:43 likewise: I have wondered about trying to catch common typos in variable names... it could be valuable Feb 08 12:18:48 GNUtoo: hi, emacs compiling finally worked, there were a lot of 'tab's in some two Makefile.in that didn't belong there Feb 08 12:19:16 ok nice!!!! Feb 08 12:21:21 GNUtoo: now I need to figure out how to make a recipe/patch out of this o_O Feb 08 12:21:49 ok Feb 08 12:21:58 can you document what you did somewhere? Feb 08 12:22:17 well I have the Makefile.in's that I changed Feb 08 12:22:29 but the original ones have gone -.- Feb 08 12:23:11 ok Feb 08 12:23:14 save everything Feb 08 12:23:28 and clean it Feb 08 12:23:31 and do: Feb 08 12:23:37 bitbake -c unpack emacs Feb 08 12:23:41 go into workdir Feb 08 12:23:47 quilt new makefile.patch Feb 08 12:23:58 quilt add /path/to/Makefile.in Feb 08 12:24:08 vim /path/to/Makefile.in Feb 08 12:24:17 or rather Feb 08 12:24:27 cp the saved Makefile.in Feb 08 12:24:33 quilt refresh Feb 08 12:24:37 and you have a patch Feb 08 12:24:48 copy the patch back into the oe metadata Feb 08 12:24:55 and add it in SRC_URI Feb 08 12:26:21 sorry, it seems my build host is offline and not reacting to wakeonlan.,. Feb 08 12:26:42 will have to try that later in the day when I can turn it on manually Feb 08 12:26:49 but thanks for the hint Feb 08 12:26:51 ;) Feb 08 12:33:56 GNUtoo: we should have bitbake -c refreshpatches package to do the latter :) Feb 08 12:36:28 lol good idea Feb 08 12:36:45 cs_nbp, ok np, thanks a lot for working on emacs Feb 08 12:37:26 hm, porting operating system Feb 08 12:37:36 ynezz: which? :) Feb 08 12:37:41 emacs Feb 08 12:37:43 :p Feb 08 12:38:55 I've pressed enter too quickly, it should've been: "hm, porting operating system to another operating system?" :) Feb 08 13:11:11 ynezz: ok, less interesting :) Feb 08 14:05:44 k changin location bb Feb 08 15:43:05 I need to create a recipe that download a binary file from ftp and place it into the final root image, does exist anything like this where to learn how do it? Feb 08 15:43:31 ftp:// is your friend Feb 08 15:43:45 you'd make it like any other recipe. add to SRC_URI, install in do_install, add the package to the image Feb 08 15:46:36 kergoth: that's what I did, I must have missed something Feb 08 15:53:49 morning kergoth Feb 08 15:55:10 GNUtoo: it's a bit different from what I thought - the build process removed the makefiles -.- Feb 08 15:55:44 GNUtoo: also I can only bitbake -b */*/emacs_23.1.bb Feb 08 15:55:55 GNUtoo: because nothing 'provides' it Feb 08 15:56:12 GNUtoo: so no bitbake -c clean emacs Feb 08 16:04:19 cs_nbp, ok what Makefiles are there? Feb 08 16:04:25 .in is usually generated Feb 08 16:04:31 at least with the current autotools Feb 08 16:04:48 usually what is not generated is configure.ac and Makefile.am Feb 08 16:05:03 and configure.in :) Feb 08 16:05:18 in this context and makefile.in.in Feb 08 16:05:23 ok Feb 08 16:05:30 oh well time to drop kids to school Feb 08 16:06:12 http://www.lrde.epita.fr/~adl/autotools.html has a good manual Feb 08 16:06:15 GNUtoo: none, the directory is empty after build Feb 08 16:06:21 s/manual/tutorial/ Feb 08 16:06:23 ok Feb 08 16:06:27 maybe you run rm_work Feb 08 16:06:35 did you save the directory somewhere Feb 08 16:06:36 ? Feb 08 16:06:42 can you pastebin your work? Feb 08 16:11:58 sry stuff going on here(at work) Feb 08 16:12:09 you mean bitbake -c rm_work? Feb 08 16:12:30 and then path to emacs_23.1.bb? Feb 08 16:12:51 nope I didn't save the directory Feb 08 16:13:02 didn't think it would suddenly vanish Feb 08 16:13:27 hi, all! Feb 08 16:13:30 could pastebin the emacs.inc but only added LIC_FILES_CHKSUM in there Feb 08 16:13:37 will have to redo everything Feb 08 16:13:41 .,. Feb 08 16:13:44 is it possible to disable rm_work for some packages? Feb 08 16:14:56 yes, you can put "do_rm_work() { : }" in the recipe Feb 08 16:14:57 how do I clean up after a bitbake -b package.bb? Feb 08 16:14:58 kergoth: in do_install() I do install -d ${D}/home/root and install -m 0644 ${S}/binoetest ${D}/home/root/binoetest and I get * opkg_install_cmd: Cannot install package binoetest Feb 08 16:15:06 or something along those lines Feb 08 16:15:22 cs_nbp: bitbake -cclean package.bb Feb 08 16:15:47 kergoth: device_table is different from the conffile in the new package Feb 08 16:15:55 mckoan: doesn't work, nothing 'PROVIDES' my package Feb 08 16:16:07 unless you added /home to your package's FILES variables, that wont do squat Feb 08 16:16:18 packages shouldn't be touching home directories anyway Feb 08 16:17:02 kergoth: yes was an example (probably the worst) Feb 08 16:18:54 kergoth: trying install -m 0644 ${S}/binoetest ${D}${bindir} Feb 08 16:19:42 kergoth: same error Feb 08 16:20:30 you need to take a step back. ignore the image. build the recipe, watch for warnings, and check deploy/ipk for the package. inspect its contents Feb 08 16:20:49 and don't forgot to clean or bump pr as appropriate Feb 08 16:25:38 kergoth: sucess! thank you so much Feb 08 16:25:43 np Feb 08 16:30:48 what do I have to do so that something 'PROVIDES' my package? the manual is not clear enough there for me Feb 08 16:31:28 nothing Feb 08 16:31:35 well... Feb 08 16:31:38 see hte default value of PROVIDES in bitbake.conf Feb 08 16:31:56 every recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR} Feb 08 16:32:50 PROVIDES = "" Feb 08 16:33:09 from bitbake.conf Feb 08 16:34:13 bitbake checked out from git Feb 08 16:34:26 changed nothing there Feb 08 16:35:14 so I should put ${PN} ${PN}-${PV} ${PN}-${PV}-${PR} between those quotation marks? Feb 08 16:35:18 cs_nbp: that version of bitbake.conf is never used in practice, look at conf/bitbake.conf in oe-core Feb 08 16:36:17 bluelightning: we should think about renaming the bitbake.conf in bitbake to bitbake.conf.sample or something Feb 08 16:36:20 to make its purpose clear Feb 08 16:36:29 kergoth: yes, that sounds like a good idea Feb 08 16:37:22 PROVIDES = "" Feb 08 16:37:22 PROVIDES_prepend = "${P} ${PF} ${PN} " Feb 08 16:37:22 RPROVIDES = "" Feb 08 16:37:32 that's what's in it Feb 08 16:37:37 yes, it is Feb 08 16:37:46 as i just told you, every recipe provides ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR} Feb 08 16:37:55 nevertheless it will complain about nothing providing my package Feb 08 16:38:02 then you're doing something else wrong Feb 08 16:38:02 cs_nbp: what's the real question? Feb 08 16:38:40 bluelightning: I compiled a package with bitbake -b *.bb and am trying to clean up after it Feb 08 16:39:01 bluelightning: giving bitbake -c clean will complain about nothing providing my package Feb 08 16:39:26 bluelightning: so will bitbake packagename Feb 08 16:39:27 cs_nbp: you should be able to do -c clean -b .bb Feb 08 16:39:53 cs_nbp: presumably that's because the bb file you've created is not anywhere within BBFILES Feb 08 16:39:54 then your recipe probably isnt' in BBFILES, check your configuration Feb 08 16:41:44 well it's in oe-tworaz/meta-jlime/recipes-apps/emacs/* right next to other apps found by bitbake Feb 08 16:42:31 well, as i already explained, your recipe already PROVIDES things unless you overrode it. so either your recipe is breaking it, or your configuration is Feb 08 16:42:38 you could try pastebin'ing the recipe Feb 08 16:44:55 ~pastebin Feb 08 16:44:56 [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. Feb 08 16:46:58 emacs.in: http://pastebin.com/Qg9WXbZP Feb 08 16:47:11 emacs_23.1.bb: http://pastebin.com/SARUUFCe Feb 08 16:50:11 cs_nbp: are you using oe (oe-classic) or oe-core? Feb 08 16:50:17 oe-core Feb 08 16:50:32 porting a recipefrom oe-classic Feb 08 16:50:50 cs_nbp: why don't you start testinf if everything works putting your 2 files in recipes/emacs/ ? Feb 08 16:51:09 cs_nbp: then learn how to manage oe layers Feb 08 16:51:22 what is testinf? Feb 08 16:51:30 cs_nbp: a typo :_D Feb 08 16:51:34 :-D Feb 08 16:51:43 s/testinf/testing Feb 08 16:52:14 a bit of dyslexia Feb 08 16:52:37 not getting what you want me to do. I could build the package with bitbake -b *.bb, what is to test? Feb 08 16:52:58 now trying to remove the remains of the build so I can do another one Feb 08 16:55:27 and that's failing because nothing 'provides' my package Feb 08 17:02:51 have a nice rest of the day Feb 08 17:08:16 kergoth: its not in the recipes, is it? Feb 08 17:10:37 and i have this layer.conf:BBFILES += "${LAYERDIR}/recipes-*/*/*.bb" Feb 08 17:11:04 and this oe-tworaz/meta-netbookpro in bblayers Feb 08 17:11:24 srz oe/tworaz/meta-jlime Feb 08 17:11:46 and the recipe is in oe-tworaz/meta-jlime/emacs/emacs_23.1.bb Feb 08 17:12:09 so according to BBFILES it should be found Feb 08 17:12:14 but its not Feb 08 17:12:53 sry path was incomplete oe-tworaz/meta-jlime/recipes-apps/emacs/emacs_23.1.bb Feb 08 17:13:28 and bbfiles says "${LAYERDIR}/recipes-*/*/*.bb" Feb 08 17:13:39 that's a match in my book Feb 08 17:14:16 all other recipes in meta-jlime/recipes-apps/ are found Feb 08 17:18:24 nvm I'll just delete my tmp/ completely again, this seems too weird Feb 08 17:18:32 cs_nbp: don't do that Feb 08 17:18:37 k Feb 08 17:19:11 cs_nbp: I can't understand what could be wrong Feb 08 17:19:47 bluelightning: me neither. if emacs_23.1.bb exists I should be able to do bitbake emacs, right? Feb 08 17:20:02 cs_nbp: the path looks correct, so yes Feb 08 17:20:05 at least when its like i said it is Feb 08 17:20:47 cs_nbp: this shouldn't make a difference, but try "touch conf/local.conf" then bitbake emacs again Feb 08 17:41:17 same result-.- Feb 08 17:41:30 cs_nbp: ok, that rules out any cache weirdness at least Feb 08 17:46:26 cs_nbp: if you touch oe-tworaz/meta-jlime/recipes-apps/emacs/emacs_23.1.bb then bitbake -p, does it indicate any files were parsed? Feb 08 17:53:23 Crofton|work: I think I've fixed the qmake thing Feb 08 17:53:27 Crofton|work: just running some tests Feb 08 17:56:50 would there be collision/conflict issues when building for different machine confs if we used the same TMPDIR ? Feb 08 17:57:33 hbeck: no, that should work fine Feb 08 17:57:39 bluelightning: it goes straight to do_compile now Feb 08 17:58:00 cs_nbp: ??? Feb 08 17:59:42 bluelightning: thanks. Feb 08 18:01:01 another question...is there a way to create a multi-system SDK for the same TARGET_ARCH (but different varieties of the hardware) using OE? Or would I have to do some kind of manual merge of the separately built SDKs? Feb 08 18:01:59 so like arm/armv4t-etc-etc-etc/ and arm/armv7-etc-etc-etc into the same SDK? Feb 08 18:02:23 hbeck: I'm not sure, I'd assume not but maybe someone else here has a better idea Feb 08 18:04:44 I would think so but it would require some mucking with TARGET_SYS, which I'm not sure I want to do... Feb 08 18:08:44 bluelightning: the last bitbake -c clean -b recipe.bb seems to have worked but anyways yielded the "nothing PROVIDES" error like before Feb 08 18:08:54 so I didnt notice it actually cleaned Feb 08 18:08:58 -.- Feb 08 18:09:50 k think this is a good place for me to try to do some steps w/o daddy ;) Feb 08 18:09:59 you should just stop using -b as a matter of principle. you should never need to use it Feb 08 18:10:28 I did't want to, but nothing 'provides' my package so no other way to compile until I found out why Feb 08 18:11:14 then find out why and fix it, don't hide it :) Feb 08 18:11:38 if it's not too embarassing I won't hide it :D Feb 08 18:11:45 yes, -b is evil Feb 08 18:13:06 we should thinka bout deprecating it, actually. the main reason it existed was due to parse times, iirc, and thats less of an issue nowadays unless your'e on a single core machine Feb 08 18:13:33 k gotta go home bb in 60 mins Feb 08 18:13:55 heh Feb 08 18:16:41 kergoth: would there be any issue with doing TARGET_SYS = ${MULTIMACH_TARGET_SYS} in my meta-toolchain-distro.bb ? related to what I asked above Feb 08 18:20:01 kergoth: you'd get violent objection to removing -b in some quarters Feb 08 18:20:13 heh, fair enough Feb 08 18:20:24 (not from me, but I know others use it) Feb 08 18:26:33 hmmm...can anyone explain the MUTLIMACH_*** vs non MUTLIMACH vars and their usage? Feb 08 18:27:27 I would miss -b if it went away, though I don't think I would object all that violently. Feb 08 18:29:59 If you wanted to make it undocumented and have it only work if you had exported BiTB4k3_h4X0r_M0d3=1 in the environment or something then I would be fairly relaxed about that. Feb 08 18:31:48 I suppose that should be "BiTB4k3_h4X0r_M0d3=1337" for consistency. Feb 08 18:34:03 to answer my own question above about issues assigning TARGET_SYS - yes there are! Apparently a change like that would have to be done at an earlier point (in a conf file) Feb 08 19:40:17 ok so I've sort of worked out the multimachine concept after hunting in the commit logs. It seems like it mainly applies to the build area. I'm still curious how one would build an SDK for a single TARGET_ARCH that would play nicely with the various machines. For example we're building for an armv4t (which uses software emulation for floating point stuff) and armv7a (which has hardware FP support) Feb 08 19:43:32 how does one get gcc to link object files together? Feb 08 19:43:46 im getting errors about not finding main() - but we are building an .so Feb 08 19:43:52 i think thought CCLD would have these already Feb 08 19:53:42 msm: what command are you using, exactly? Feb 08 19:56:25 pb_: i was missing a "-shared" Feb 08 19:56:38 i assumed CCLD might provide that Feb 08 19:57:00 or rather I'm just wingingit Feb 08 19:57:14 turns out we need to override LDSHARED for distutil builds because it uses a cache value which could be wrong Feb 08 19:57:18 to sort of summarize my issue Feb 08 19:57:29 i'll be sending a patch to the list shortly Feb 08 20:15:01 hbeck: thats a lot of work to put together a multimachine SDK Feb 08 20:15:30 hbeck: OE is intentionally simple minded in this regard Feb 08 20:16:36 CCLD means use CC to do linking Feb 08 20:21:06 khem: well, I have no issues just building two separate machine SDKs which both have a TARGET_ARCH="arm" and then combining them into a single directory structure if that's possible. What I'm trying to solve right now is to change the name given to the system specific files/libraries from something like ARCH-VENDOR-OS to MULTI_ARCH-VENDOR-OS Feb 08 20:21:19 and then keep the generic files as they are with ARCH-VENDOR-OS Feb 08 20:22:26 so I'd get something like arm/bin/ and arm/armv4t-blah-blah-linux plus arm/armv7a-blah-blah-blah Feb 08 20:22:35 after combining Feb 08 20:37:45 khem: that's what's goign on Feb 08 20:38:02 khem: or that's what distutil's is using to do linking Feb 08 20:38:03 AFAIK Feb 08 20:47:00 hbeck: what specific libs go into say arm-oe-linux-gnueabi convention Feb 08 20:48:20 compilers should go into dir Feb 08 20:48:31 but they will still be called Feb 08 20:48:42 arm-oe-linux-uclibceabi- Feb 08 20:49:22 khem: gcc, pthread, stdc++, util, thread. I was more looking at which things were an ARM file vs x86 file for the dev machine Feb 08 20:50:33 ah, we didn't install to root...but we have a /opt/distro/arm/bin/ which has the binaries Feb 08 20:51:09 and then tehre's /opt/distro/arm/arm-vendor-linux-gnueabi/bin/ which has the short names for the binaries but are symlinked to the above dir Feb 08 20:52:40 what's the main thought in difference between BASE_PACKAGE_ARCH and TARGET_ARCH ? Feb 08 20:53:36 base package arch is lowest supported sub family Feb 08 20:57:47 would it be completely against the "point" of the variables to force-set TARGET_SYS to use MULTI or BASE (which end up being the same in the cases I have looked at) ? Feb 08 21:03:03 hbeck: a lot depend on these vars Feb 08 21:03:20 I cant even envision what all can break because of these vars Feb 08 21:03:27 heh Feb 08 21:04:24 multimach was done to accomodate multiple builds of similar enough arches Feb 08 21:04:33 right Feb 08 21:04:37 in same tmpdir Feb 08 21:05:01 but no real carry-over to building SDKs in the same fashion Feb 08 21:05:11 yeah Feb 08 21:05:19 I think what we're trying to avoid is having to provide different SDK downloads/installs to the users who get the SDK. We'd like to be able to give them a single SDK install that covers all the targets we support Feb 08 21:05:35 one day I will revisit SDK and straighten some niggles in there Feb 08 21:06:29 hbeck: it should live together for armv4 and armv7 Feb 08 21:06:43 hbeck: but sysroot might be what conflicts hmm Feb 08 21:06:58 can you post the install tree org chart Feb 08 21:08:07 hrm. Lost me a bit in what you're asking for Feb 08 21:08:26 issue a find command in your install tree of SDK Feb 08 21:08:29 how we install the SDK? Feb 08 21:08:32 and paste that output Feb 08 21:09:12 yes I want to see where what goes in install Feb 08 21:10:24 heh. pastebin says it is too big Feb 08 21:10:36 somewhere else I can stick it? Feb 08 21:11:48 http://paste2.org/p/1898307 Feb 08 21:12:24 khem: there we go. Note that right now we have a x86 SDK and only a single arm (v4) SDK in the install. We want to add the armv7 Feb 08 21:14:38 hi Feb 08 21:15:01 is there any tutorial on how to modify a board.c file and get bitbake to use the new file? Feb 08 21:18:03 i don't understand how recipes work. i know that "bitbake console-image" will get me the files i need to run my beagleboard, but i don't know how to get from there to the source code Feb 08 21:18:22 rlrosa: you need to modify one of the source files in a recipe? Feb 08 21:18:46 or rather, from the source a recipe uses Feb 08 21:24:13 hbeck, yes. i want to change the beagleboard board file, i want to modify i2c speed Feb 08 21:24:47 do you know of which package that file is a part? Feb 08 21:24:57 hbeck, and i would like to learn a bit more about how to change stuff in oe, it's all kind of "magical" to me (magical == i have no idea what does what) Feb 08 21:26:05 rlrosa: well there's the (outdated) OE user manual pdf that's pretty easy to find. Some of it is still valid and might give you a general idea. Feb 08 21:28:51 rlrosa: and the short answer for your board.c question is that if it is a source-level change you will want to create a patch for board.c and add the patch file to the appropriate recipe...usually I do that in my distro overlay directory and just use a .bbappend to the recipe in the main tree area. Feb 08 21:28:57 i found the file in at setup-scripts/build/tmp/work/beagle.../linux-3.../git/arch/arm/mach-omap2/board-omap3beagle.c, but i put garbage into it and console-image compiled without complaining, so i'm pretty sure it's not using it Feb 08 21:29:57 hbeck, i'm not familiar with the concepts you're using, such as "main tree area" and bbappend, should the old pdf give me and idea of that stuff? Feb 08 21:30:01 yes Feb 08 21:31:23 as a warning though it is written for the oe-classic tree (which I am still using) and not the new oe-core. So I couldn't tell you if some of the concepts have been replaced or changed Feb 08 21:35:28 hbeck, i foind the manual. is it easy/possible to get the classic oe instead of the new one? Feb 08 21:35:48 rlrosa: why would you want classic oe Feb 08 21:36:42 khem, because the manual is about the classic one. i'd think it would be easier to understand following the manual, and then port whatever i learned to the new version Feb 08 21:37:24 khem, do you *not* recommend this? Feb 08 21:37:37 rlrosa: actually I would not Feb 08 21:40:36 khem, ok. i'll see if i can "port on the go" Feb 08 21:42:41 rlrosa: actually it will be better if you can document the problems and things that need update Feb 08 21:45:10 khem, i found this pdf http://code.google.com/p/openembedded/downloads/detail?name=usermanual.pdf any clue where to find the .tex version of it? (assuming it exists) Feb 08 21:46:56 khem: any insight from the install paste for SDK? Feb 08 21:49:11 rlrosa: you could clone git://git.yoctoproject.org/yocto-docs Feb 08 21:49:19 that should cover oe-core to some extent Feb 08 21:52:23 old documentation is here http://git.openembedded.org/openembedded/tree/docs/usermanual Feb 08 21:55:46 hbeck: I see. there is no multimachine there Feb 08 21:58:20 not currently. and I don't think we have a way to do a multimachine install, because of the higher level TARGET_ARCH specification (arm) on most stuff instead of using the MULTI (armv4, v7) Feb 08 21:58:40 I've built in separate build dirs the sdk for both arm machines Feb 08 21:59:08 khem: but they build a nearly identical tree for ./arm/ ... Feb 08 22:00:12 hbeck: yeah I think propagating multimachine to target triplet might be the solution Feb 08 22:00:21 but thats quite fundamental Feb 08 22:00:43 fundamental as in easy or as in a low level change that could screw up everything else? :) Feb 08 22:03:37 khem: and would that be a distro override or something you're thinking could change in bitbake.conf (or maybe the sdk class?) Feb 08 22:03:50 no it has to be deeply rooted Feb 08 22:04:02 but for you I think you can define a variable Feb 08 22:05:15 hbeck: btw. is it using oe.classic Feb 08 22:05:29 khem: yes Feb 08 22:05:35 oh boy Feb 08 22:05:41 nothing will get fixed there Feb 08 22:07:22 khem: didn't expect so, but the boss doesn't want to pay for the time to move all our stuff over to oe-core Feb 08 22:08:01 hbeck: hmm ok Feb 08 22:08:09 hbeck poor boss Feb 08 22:08:51 woglinde: wie gehts Feb 08 22:08:56 woglinde: heh. To make it worse we started using oe and got everything working ... just barely a couple months before the switch to oe-core happened Feb 08 22:09:24 hbeck: migration should be easier but its some work Feb 08 22:09:31 but opens up your future Feb 08 22:09:49 khem: so for a variable do you mean just a reassignment of TARGET_SYS triplet to the MULTI_TARGET_SYS in my distro conf file or something? Feb 08 22:10:28 hbeck: you can try Feb 08 22:10:54 khem: yeah well a couple things holding us from migration - priorities, time investment required, and not entirely sure as to the "method to the madness" as it were (why was the switch done?) Feb 08 22:12:37 hbeck: oh well. Its done for a reason and stability and dead code were main reasons Feb 08 22:13:27 khem is there a summarized list discussion or blog or something that covers the impetus for the move? such as those reasons you mention. Feb 08 22:16:19 hbeck: yes it was disussed on ml a lot Feb 08 22:17:59 khem: right, but I assume that was multiple threads over a decently long period of time. was hoping for a summary of some kind :) Feb 08 22:19:05 hbeck: I pretty much gave you Feb 08 22:19:10 got it Feb 08 22:19:22 hbeck: other reasons were we used push model which was not scaling Feb 08 22:19:43 as the meta-data grew so large it was broken every instant Feb 08 22:20:26 so we bit the bullet and I am happier than before Feb 08 22:20:26 well a simple TARGET_SYS = ${MULTIMACH_TARGET_SYS} fails on build due to provider issues :( Feb 08 22:20:38 I am not surprised Feb 08 22:20:50 actually wait, those are just notes. Feb 08 22:20:55 ERROR: Task /oe/openembedded/recipes/gcc/gcc-cross-intermediate_4.5.bb (do_setscene) has circular dependency on /oe/openembedded/recipes/eglibc/eglibc_2.12.bb (do_setscene) Feb 08 22:20:59 ^ is the error Feb 08 22:21:26 yeah we have sanitized toolchains quite a bit in oe-core Feb 08 22:21:32 separated the target bits out Feb 08 22:21:38 for better dep tracking Feb 08 22:21:45 created intermediate sysroots Feb 08 22:37:32 khem: in sight of meta-oe reorganization, what should happen to klibc? Feb 08 22:44:13 good nite Feb 08 22:44:33 ant____: that belongs to meta-initramfs may be Feb 08 23:35:39 bluelightning: sorted it, filesystem was corrupted Feb 08 23:36:18 cs_nbp: wow, ok... never would have guessed that :o Feb 08 23:36:42 no wonder weird stuff was happening... Feb 08 23:36:48 y Feb 08 23:36:58 hmm did someone bribe it or what :) Feb 08 23:37:04 how did it got corrupted Feb 08 23:37:14 there was a power surge in my office Feb 08 23:37:31 when I went to restart the computer it took really long Feb 08 23:37:43 but no error messages Feb 08 23:37:50 so I didn't bother at first Feb 08 23:37:59 then weird things happening in oe Feb 08 23:38:08 and later in other applications too Feb 08 23:38:29 which fs? Feb 08 23:38:37 yeah I have seen OE is pretty upset when I run out of diskspace and then restart the build after freeing up some Feb 08 23:38:48 it does not like the intermediate files Feb 08 23:38:56 xfs Feb 08 23:39:17 xfs isnt that like storage server recommended one Feb 08 23:39:32 proabbly you are better off with ext4 Feb 08 23:39:46 I hard reboot my box many times Feb 08 23:39:57 when ubuntu compiz bites me backsize Feb 08 23:39:58 I have heard a lot about XFS being poor at handling unexpected events like surges Feb 08 23:39:59 side Feb 08 23:40:01 yes that machine needs a new setup anyway Feb 08 23:40:17 it was my first xfs failure ever Feb 08 23:40:25 khem: RP__ tells me that's gcc Feb 08 23:40:31 and I didnt like how sneaky it was Feb 08 23:40:45 cs_nbp: never tried it myself, only going by what I read... Feb 08 23:41:15 well probably there is some people who didnt notice their xfs is corrupted Feb 08 23:41:16 bluelightning: you mean the one which bites the backside :) Feb 08 23:42:05 khem: well, I guess it just has no code to delete files that are partially written in the case of insufficient space Feb 08 23:42:15 bluelightning: gcc? Feb 08 23:42:30 RP__: isn't that what you were suggesting when we talked about this last time? Feb 08 23:42:30 * RP__ found xfs painful for OE use Feb 08 23:43:07 bluelightning: I'm not making sense of the conversation, sorry Feb 08 23:43:20 bluelightning: the out of disk space being a gcc issue? Feb 08 23:43:25 RP__: yes Feb 08 23:43:40 bluelightning: its not gcc as such, just that you can end up with zero length files lying around Feb 08 23:43:41 RP__: it's a side bit in a discussion about general file system corruption Feb 08 23:43:43 when disk is full and build halts free some space restart the build and it does not start from where it left like it usually will do Feb 08 23:43:45 and gcc doesn't like that Feb 08 23:43:58 right, that's what I was referring to Feb 08 23:44:05 yes 0 length files is the real problem Feb 08 23:44:10 can also confuse make Feb 08 23:44:45 yeah but with sstate it does not matter that much Feb 08 23:44:48 yes, I would imagine that could happen as well Feb 08 23:45:01 khem: well ideally you'd like it to be resumable Feb 08 23:45:12 RP__: btw. for fun since machine was bored I am doing a funny build where I am building each recipe from scratch Feb 08 23:45:28 with sstate it helps Feb 08 23:45:43 and I hope to get some missing dependencies Feb 08 23:45:47 khem: yes, I've meant to script that Feb 08 23:46:19 http://paste.ubuntu.com/834624/ Feb 08 23:47:14 khem: nice and simple :) Feb 08 23:47:26 khem: It will be interesting to see how many issues we really have Feb 08 23:47:45 yes Feb 08 23:48:23 even more interesting if you enabled buildhistory while doing that Feb 08 23:48:40 that would pick up any unstated dependencies Feb 08 23:48:43 bluelightning: yes i will do that once I get through one pass Feb 08 23:48:45 or, at least some of them Feb 08 23:48:53 hmmm Feb 08 23:49:03 great idea though Feb 08 23:49:03 this time I will just rely on build failure Feb 08 23:49:57 so far 1 package is done Feb 08 23:49:59 :) Feb 08 23:50:09 but it worked Feb 08 23:50:31 which is it? hello_world? .p Feb 08 23:50:39 libffi Feb 08 23:51:37 'portable foreign function library' omg Feb 08 23:51:52 if that can work Feb 08 23:51:57 means lot will work Feb 08 23:52:46 RP__: btw. I have a working toolchain with llvm + compiler-rt + libc++ + binutils Feb 08 23:52:47 for arm Feb 08 23:53:00 it just needs the linker from binutils Feb 08 23:53:21 ah yeh the gcc seems broken on my target Feb 08 23:53:54 RP__: for x86 it did not need binutils Feb 08 23:53:59 'cannot find crtbegin.o' when compiling a hello-world level code Feb 08 23:54:07 I am not sure if it sneaked the host one :) Feb 08 23:54:29 cs_nbp: that definitely means your runtime is borked Feb 08 23:55:27 if llvm was so mature we would build cross compiler only _once_ for all arches how cool is that Feb 08 23:55:32 khem: cool :) Feb 08 23:55:38 and it does not need any deps on libc and crap Feb 08 23:55:41 very kewl Feb 08 23:56:26 khem: does that mean im missing a package or that the gcc recipe doesnt work well for that target? Feb 08 23:56:28 khem: might help some of our build time issues? :) Feb 08 23:56:47 RP__: yes indeed Feb 08 23:56:53 will simplify the things Feb 08 23:57:07 cs_nbp: do you have gcc-runtime installed on target ? Feb 08 23:58:00 khem: seems only gcc-runtime-dbg is there -.- Feb 08 23:58:14 I think there is a lot of gcc'ism in the packages that it will take ages for it to really become prominent Feb 08 23:58:29 cs_nbp: not good. Feb 08 23:59:23 oe infra full stop on wiki/git(master) in 2 minutes Feb 08 23:59:26 window for 2hrs Feb 08 23:59:53 ka6sox: thanks Feb 09 00:00:01 also sources.openembedded.org Feb 09 00:00:09 hopefully they dont have xfs :) Feb 09 00:00:15 jfs Feb 09 00:00:24 and soon ocfs2 Feb 09 00:00:37 hmm Feb 09 00:00:49 soon means after this reboot Feb 09 00:01:30 khem: in deploy/ipk/* there is only gcc-runtime-dbg gcc-runtime-locale-de and gcc-runtime-locale-fr Feb 09 00:01:38 no, on new infra I am bringing online **** ENDING LOGGING AT Thu Feb 09 00:04:03 2012 **** BEGIN LOGGING AT Thu Feb 09 00:12:16 2012 Feb 09 00:13:27 after bitbake -c clean gcc-runtime and bitbake gcc-runtime i still only get those packages Feb 09 00:13:32 and no errors Feb 09 00:13:52 oe-core/meta/recipes-devtools/gcc/gcc-runtime_4.6.bb Feb 09 00:24:39 ml and patchwork don't seem to contain something connected to this Feb 09 00:31:07 (newest git checkout of course) **** ENDING LOGGING AT Thu Feb 09 00:58:30 2012 **** BEGIN LOGGING AT Thu Feb 09 01:10:18 2012 Feb 09 01:10:28 k gn8 Feb 09 01:14:18 khem, should be back up again Feb 09 01:51:39 ka6sox-away: yes I can confirm git is up **** ENDING LOGGING AT Thu Feb 09 02:59:57 2012