**** BEGIN LOGGING AT Thu Feb 21 02:59:59 2013 Feb 21 03:53:24 I seek second opinions on a design question. Summary: mips64-vendor-linux-gnun32. Feb 21 03:53:40 gnun32 should probably not have SITEINFO_BITS = 64. Feb 21 03:53:54 But it really should be (I am told by MIPS people) considered a kind of mips64. Feb 21 03:55:58 So in insane.bbclass, linux-gnun32 is a heading, under which we have mips64 and mipsel64 pointed at 32-bit. Feb 21 03:56:34 ... Which is odd, given that it's mips64el up above. I may have introduced a typo there, which would likely have gone unnoticed since I don't think anyone else uses gnun32, and I don't think we have any little-endian n32. Feb 21 03:58:54 Anyway, looking at siteinfo.bbclass, trying to think of a way to express this madness reasonably coherently. Feb 21 03:59:41 My best idea so far is to suggest checking for target in archinfo before hostarch in archinfo, and then add mips64-gnun32 entries to the arch list, but that... seems sorta ugly at best. Feb 21 04:00:15 Alternatively, some kind of subtractive feature, where something could look up mips64-gnun32 and find that it should remove bit-64 from its siteinfo list. Feb 21 04:11:05 Oh, nevermind. This is already fixed in master oe-core, by the much simpler expedient of preferring bit-32 if it's set. Clever! Feb 21 08:06:55 hi, is there a x86 'lm-sensors' yocto recipe ? Feb 21 08:07:23 or similar to read cpu temp. Feb 21 08:38:41 good morning Feb 21 09:50:50 morning all Feb 21 10:06:10 gm bluelightning all Feb 21 10:17:49 good morning~ Feb 21 13:20:21 Heya - I remember doing an earlier build of yocto and getting a full toolchain out but I'm using danny at the moment and it only seems to output an sdk scripts. How do I get just the tar.gz ? Feb 21 13:24:55 exosyst: it's a relocatable SDK now, so you run the script and it will ask you where you want to extract to Feb 21 13:25:40 jackmitchell, Did not know that, can it be scripted? Feb 21 13:26:10 exosyst: not sure, sorry Feb 21 13:28:24 jackmitchell, Hmm, I guess I can just do echo -ne "/opt/poky" | sh poky-eglibc-i686-arm-toolchain-1.3.sh and hope for the best Feb 21 13:28:47 I think you have to confirm somewhere too Feb 21 13:29:05 echo -ne "\ny" | sh poky-eglibc-i686-arm-toolchain-1.3.sh Feb 21 13:29:05 Enter target directory for SDK (default: /opt/poky/1.3): You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?Error: Unable to create target directory. Do you have permissions? Feb 21 13:29:21 That works, gotta sudo that stuff tho but I can work with that Feb 21 13:29:40 Just nice to know when it changed and why - some sort of log... like, of changes? :D Feb 21 13:29:54 I almost got round to writing a patch the other day that lets you specify the extract directory as an argument Feb 21 13:30:23 jackmitchell, I could do it in moments.. no idea how/where to submit it tho Feb 21 13:31:22 exosyst: it was in the release notes Feb 21 13:32:27 bluelightning, i have so much reading to do but yeah, i was hinting that I should read the changelogs haha Feb 21 13:55:44 Hi all, I have a question, is there any way how to export the variable from the recipe? I need to know the kernel version during creating rootfs. Feb 21 14:02:32 matus: not normally no Feb 21 14:03:19 matus: you should be able to determine the kernel version installed at do_rootfs time though Feb 21 14:03:52 matus: you could use the packaging system, or explicitly write a file as part of the kernel with the version in it Feb 21 14:42:53 hello i have a question how do i change the hostname of the distro i whant to build is it best to write a new recipe or is there a gentler way ? Feb 21 14:44:31 this keeps on coming up Feb 21 14:45:00 * rburton tries to remember the right incantation Feb 21 14:45:24 hostname_pn-base-files = "my-distro-rocks" Feb 21 14:45:55 drop that in your distro configuration, or local.conf, or anywhere Feb 21 14:46:11 or, bbappend basefiles and just set hostname in there Feb 21 14:51:47 worked like a charm thx Feb 21 14:58:39 Hi! i'm trying to add firefox to a core-sato-image (for pandaboard)...adding meta-openembedded/meta-gnome layer (required by meta-browser as stated in meta-browser/README file) I've got this error: "NOTE: Error expanding variable populate_packages ... ERROR: Unable to parse ~/meta-openembedded/meta-gnome/recipes-support/goffice/goffice_0.8.17.bb" Feb 21 14:58:50 someone can tell me what this means? Feb 21 14:58:57 thanks! Feb 21 15:01:14 soldoKyn: likely means the branch you are using for the meta-openembedded repository does not match up with the branch of OE-Core you are using Feb 21 15:01:46 soldoKyn: there were changes that broke compatibility between the denzil and danny/master branches Feb 21 15:02:37 so I have to switch from denzil to danny? Feb 21 15:03:07 or switch your meta-oe repo to a denzil branch Feb 21 15:04:35 bluelightning-rburton: ok, thank you a lot! Feb 21 15:06:04 we really ought to set versioned layer dependencies in other layers so that this is explicit Feb 21 15:06:22 I did set the version in OE-Core so that that would be possible Feb 21 15:06:22 Ahoy, I think i've found a bug in the definitiion for the meta-toolchain. The environment script sets LDFLAGS that aren't understood by the bfd version of ld. Feb 21 15:06:22 agreed Feb 21 15:26:49 <_Lucretia__> anyone know what the pvrsrvinit is called now? or if we need it? is it pvrsrvctl? Feb 21 15:27:06 * _Lucretia__ is almost at the point of getting sgx on gumstix Feb 21 15:29:54 <_Lucretia__> looks like it is Feb 21 15:46:53 <_Lucretia__> is there a way to force the build of the rootfs without checking the deps or make it ignore them? I just need a test Feb 21 15:48:24 <_Lucretia__> or, how do I fix this? http://pastebin.com/4e41siWi Feb 21 16:41:31 Hi all, say I have some shell script in my SRC_URI that I want to execute when building an image. Is there a place where the stuff in SRC_URI gets put? Feb 21 16:41:44 is there some function in which that happens? Feb 21 16:41:51 Garibald1: all files in SRC_URI get put into ${WORKDIR} Feb 21 16:42:03 n the "fetch" task Feb 21 16:42:45 rburton: thanks Feb 21 16:45:58 so if image.bbclass does a do_fetch[noexec] = "1" and I inherit from it, can I in turn do a do_fetch[noexec] = "0" to re-enable that task? Feb 21 16:49:21 or is there a better way Feb 21 16:49:52 I had the script in another location, but that seemed not to be the best solution Feb 21 16:53:38 Basically I want to introduce a new image target that does everything the existing one does, then turns the rootfs into an image for a VM Feb 21 16:53:48 I have a script to do it, and I'm trying to tie that into the build process Feb 21 16:54:23 I thought I'd stick the script in the SRC_URI for the recipe, and could execute it after the rootfs is created, but I'm having trouble getting the script Feb 21 16:58:49 any suggestions? :) Feb 21 17:10:11 how do I add opkg to my Poky rootfs? I thought I could add IMAGE_FEATURES += "package_management" and that would work? Feb 21 17:11:38 that's the theory, assuming you're using ipkg packages Feb 21 17:14:34 IMAGE_FEATURES += "package_management" Feb 21 17:14:34 PACKAGE_CLASSES ?= "package_ipk" Feb 21 17:14:38 rburton, ^ Feb 21 17:15:02 totally should work Feb 21 17:15:40 oh Feb 21 17:15:43 package-management, not _ Feb 21 17:16:30 I had package-management first time, just tried with it as an underscore and no difference Feb 21 17:17:01 is your image inheriting core-image? Feb 21 17:18:14 uh, not sure. How would I check that? Feb 21 17:19:07 look at your image recipe Feb 21 17:19:28 I'm just using core-image-minimal, I imagine that should be fine? Feb 21 17:19:51 you mean the image that has at then end Feb 21 17:19:55 ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; " Feb 21 17:21:11 rburton, ah bum. I thought that would be overridden by asking for package-management? Feb 21 17:21:16 nope Feb 21 17:21:20 image-features are just package sets Feb 21 17:21:40 you could argue that the lack of package-management should imply removal of packaging data Feb 21 17:22:14 i'd start by copying core-image-minimal and extending it Feb 21 17:22:18 I would've thought so. So i'm confused, I don't want to have to mess with the default image-recipe but I definitely want package management. Feb 21 17:22:44 Is there a guide for it (or if it's trivial, would you mind walking me through it?) Feb 21 17:22:55 the minimal recipe is pretty obvious Feb 21 17:24:34 hi, does anybody use yocto with ubuntu 12.10? I know that it works with 12.04, and wonder if 12.10 is OK as well. Feb 21 17:25:29 rburton, It is, I remove that line. But I'd prefer not to cludge this and create a proper recipe (not in the meta/recipes-core/images/ directory) if that's the right thing to do Feb 21 17:25:29 dv_: master supports 12.10 and i don't think anything had to be fixed Feb 21 17:45:32 rburton, maybe you can help - I added my layer as a BBLAYERS = "" /path/to/layer/" and am getting: WARNING: No bb files matched BBFILE_PATTERN_meta-bespoke Feb 21 17:46:21 does your layer have a conf/layer.conf file? Feb 21 17:47:39 yeah - http://pastebin.com/c2N6tY5x Feb 21 17:48:56 rburton, and thats the bblayers.conf http://pastebin.com/jvzw31Ww Feb 21 17:49:23 incidentally it flags the meta-ti one too with the same error but I don't use a recipe from there Feb 21 17:51:36 exosyst: hm. meta-yocto uses different ways of appending, but i can't see anything obviously wrong Feb 21 17:54:54 must be something else, i've done. So the bare minimum recipe should just omit the ROOTFS_POST_PROCESS_COMMAND? I don't need to add opkg to my feature list? Feb 21 17:59:30 rburton, got it - I hadn't moved my .bb into images (left it one directory up!) Feb 21 17:59:46 :) Feb 21 18:00:46 rburton, So I went from the notes I cribbed at the Yocto talk in ELCE, is there better documentation available for it? Feb 21 18:36:56 i'm building yocto for fri2 board... i need to tweak some kernel options only for this build... how is the recommended way to configure it? Feb 21 18:37:18 i tried: bitbake virtual/kernel -c menuconfig Feb 21 18:37:36 i'm able to configure the kernel, but in the end it's not in the final image Feb 21 18:37:53 where does it save the .config file? Feb 21 18:38:20 recipes emit packages, packages get installed into images. running menuconfig isn't going to magically put the file into your rootfs Feb 21 18:38:40 kergoth: yes, but after that i build the image Feb 21 18:39:20 so what do you mean by "it's not in the final image"? no kernel is in the image at all, or the contents didn't get updated reflecting the new configuration? Feb 21 18:39:47 kergoth: the contents didn't get updated Feb 21 18:41:30 hum... does each kernel module have its own package? Feb 21 18:42:20 but I already tried letting the option built in the kernel as opposed to as a module, and it didn't help Feb 21 18:42:44 seems like my new built kernel didn't get into the image Feb 21 19:09:47 Speaking of image recipes, is there any "good" way to include a script needed to build an image? Feb 21 19:10:54 I tried adding a SRC_URI for my recipe, but image.bbclass hass do_fetch[noexec] = "1" Feb 21 19:11:19 and doing do_fetch[noexec] = "0" in my recipe didn't seem to turn it back on Feb 21 19:12:08 the = "0" has to be -after- the inherit Feb 21 19:12:18 yeah, that's where I put it Feb 21 19:12:34 then the alternative is generate foo-native recipe.. require that in the image.. and use the script that way.. Feb 21 19:12:45 if you are providing a script (that ends up on the target) make it a target recipe instead Feb 21 19:13:04 yeah, I thought of having a foo-native Feb 21 19:13:46 but in addition to the script there's are a few xml files that I need as well Feb 21 19:14:15 I guess I could install them in the native env, then figure out where they're at and grab them Feb 21 19:14:45 but that seems a bit hackery Feb 21 19:14:54 if you want to execute them.. put them into ${D}${bindir}/... Feb 21 19:15:01 if you want to copy them to the target, make a target recipe Feb 21 19:15:49 well, I want to execute a script after the rootfs is build and pass to the script the rootfs an an xml file Feb 21 19:16:12 so neither the script nor the xml file shoudl be on the target Feb 21 19:16:24 we do that in our products.. we added a class to automate that process.. but really all that is needed is the script added to the ROOTFS_POSTPROCESS variable Feb 21 19:16:42 the script should just be in the bindir.. and the xml file in a "known" location.. Feb 21 19:16:51 ok, sounds good -- thanks Feb 21 19:16:51 it wasn't too hard when we did it Feb 21 19:17:18 yeah, I'm just trying to find the best approach. Feb 21 19:49:50 rburton: and yocto 1.3 / poky danny? Feb 21 19:49:55 do you expect problems? Feb 21 20:02:17 fray: Okay, I have a -native package with my script and xml files, and my image recipe depends on that new -native package. How do I refer to the locations where the script and xml files are stored within my image's recipe? Feb 21 20:02:40 dv_: nope Feb 21 20:02:47 as long as the script-native's do_install copies it to ${D}${bindir}/. it should be in your path.. just make sure it's executable Feb 21 20:03:10 okay, for the script I understand that, what about the xml files? Feb 21 20:03:18 as for the xml files.. it's wherever you copied it in the do_install.. ... but let me find the right variable set for you Feb 21 20:03:40 I put them in ${D}${datadir} Feb 21 20:04:09 STAGING_DATADIR_NATIVE Feb 21 20:04:27 ah, ok Feb 21 20:04:34 Garibald1: bitbake.conf is the place to look for all variables, path related, and most others to be honest Feb 21 20:04:46 rburton: ahh, that's good to know Feb 21 20:04:49 yup.. thats what I did.. you just have to have an idea fo what to look for.. Feb 21 20:05:02 that's what I'm missing :) Feb 21 20:05:05 the STAGING_..._NATIVE si what I've had to use before.. I just couldn't remember the exact format.. Feb 21 20:08:56 hum, so my file ended up in tmp/sysroots/qemux86/usr/share/foo.xml but ${STAGING_DATADIR_NATIVE}/foo.xml got me tmp/sysroots/x86_64-linux/usr/share/foo.xml Feb 21 20:09:13 clearly I did something wrong, any idea what? Feb 21 20:10:20 if it went into qemux86, then are you sure you did it in a -native recipe? By inheriting native it should have changed the value of bindir/datadir,etc.. Feb 21 20:10:31 doh Feb 21 20:10:35 Garibald1: native recipes don't become native by their suffix :) Feb 21 20:10:46 :) Feb 21 20:11:03 you can do something like BBCLASSINHERIT=native in your script.bb to make it magically have normal and native versions if that's useful Feb 21 20:11:11 or if its always native, just inherit native. Feb 21 20:11:17 but now food Feb 21 20:11:24 rburton: thanks Feb 21 20:12:14 success! Feb 21 20:12:26 fray: thank you very much for the guidance Feb 21 20:12:34 np Feb 21 21:25:27 hm, how can I disable the ncurses task output? I want to do a dry run, and would like to see the list of tasks that would get executed Feb 21 21:25:39 just redirect to a file or | tee Feb 21 21:25:49 it only uses interactive if it's writing to a tty Feb 21 21:26:17 when writing to something other than a tty, it defaults to the old ui, without the task summary Feb 21 21:27:30 ah, thanks Feb 21 21:29:58 np Feb 21 21:55:33 seebs: explain linux-gnu32 a bit to me please Feb 21 21:56:05 Okay. I have only partial comprehension, but... Feb 21 21:56:30 It has been explained to me that the "n32" ABI is, in some fundamental way, part of the mips64 architecture rather than the mips32 architecture. Feb 21 21:56:39 thats correct Feb 21 21:56:59 Thus, if you're doing a proper host triplet, it should be mips64-vendor-linux-gnun32-gcc, not mips-vendor-linux-gnu-gcc. Feb 21 21:57:09 but nothing that changes basic type system Feb 21 21:57:30 The problem is that there's a bunch of things which make the reasonable assumption that, if you are building for mips64, you are targeting a 64-bit system. Feb 21 21:57:50 what assumptions Feb 21 21:57:54 Thus, for instance, insane.bbclass has to know that mips64-linux-gnun32 wants 32-bit binaries. Feb 21 21:58:20 well N32 appears as N32 binary Feb 21 21:58:21 Before the patch to add recognition of linux-gnun32, insane.bbclass would freak out, because it expected 64-bit binaries and found 32-bit binaries. Feb 21 21:58:29 its neither N64 nor O32 Feb 21 21:58:39 Right. Feb 21 21:59:16 But "file foo" produces "ELF 32-bit MSB ... MIPS, N32 MIPS64 rel2..." Feb 21 21:59:35 we should not invent another triplet Feb 21 21:59:49 yes the binary is still 32bit Feb 21 22:00:04 or can be treated like Feb 21 22:00:10 So, before a patch I sent some months back, if you actually configured for n32, and built stuff, insane.bbclass blew up. Feb 21 22:00:11 since the type system is 32bi Feb 21 22:00:12 t Feb 21 22:00:23 It looked up the architecture, noticed it was mips64, and expected to see "ELF 64-bit". Feb 21 22:00:35 so fix insane class Feb 21 22:00:39 We did. Feb 21 22:00:47 how Feb 21 22:00:50 gnun32 works the same way gnux32 does for x86. Feb 21 22:01:15 is it accepted widely ? Feb 21 22:02:04 I don't know about "widely", but it's how things have been done in oe-core for a while, apparently. See package_qa_get_machine_dict. If your ABI is special, you create a linux-ABI entry, like "linux-gnux32" or "linux-gnun32", and put your architecture in there. Feb 21 22:02:05 I am probably missing what part of insane would not understand N32 Feb 21 22:02:55 If you look at the get_machine_dict thing: Take out linux-gnun32, make an n32 system, and you'll get QA errors because the architecture check looked up "mips64" and concluded it should see 64-bit executables. Feb 21 22:03:07 if I now configure for N32 then my gcc is called mips64-oe-linux-gnun32-gcc ? Feb 21 22:03:14 Yes. Feb 21 22:03:20 oh boy Feb 21 22:03:38 I wish I looked at ml more Feb 21 22:03:39 The change I sent out today fixes a typo in the old one (I spelled mips64el as mipsel64), and fixes siteinfo to do the same thing, roughly. Feb 21 22:04:09 The problem biting us was that when we built for n32, siteinfo ended up concluding that SITEINFO_BITS should be 64. Feb 21 22:04:24 but that could be fixed internally to OE Feb 21 22:04:30 and not change triplets Feb 21 22:04:31 IMO Feb 21 22:04:43 n32 could just be a tune feature Feb 21 22:05:07 how do you differentiate between mip64 (n64) and mips64 (n32) w/o the triplet? the tune is one way, but none of the insane or other classes use the tunes.. they all use the triplets.. Feb 21 22:05:17 That could probably be done, but... yeah, that basically. Feb 21 22:05:19 file utility can figure out N32, O32, O64, N64 nicely Feb 21 22:05:23 this would require a fairly major change to insane and other classes that have the tables Feb 21 22:05:25 why cant we leverage that Feb 21 22:05:36 Yes, but siteinfo can't use the file utility to guess what SITEINFO_BITS should be. Feb 21 22:06:02 I guess my main point is: I think n32 MIPS should parallel x32 x86/x86_64. Feb 21 22:06:16 personally I'd rather have the SITEINFO_BITS in the tune files.. but that was rejected "way back when" for some reason.. Feb 21 22:06:28 And the way that does it is that targetinfo has an entry for x86_64-linux-gnux32 which specifies bit-32. Feb 21 22:06:41 ...and as you said, we need a way to differentiate the cross compilers as well.... Feb 21 22:06:53 since triplets are used in the cross compiler name(s) and sdk files Feb 21 22:06:55 So all this patch does is continue the previously-established alignment of n32 and x32. Feb 21 22:07:10 fray: N32 was intermediate step Feb 21 22:07:26 it could be eliminated too Feb 21 22:07:36 but thats besides point Feb 21 22:08:15 I am only worried if gnun32 is well supported in gnuconfig and friends Feb 21 22:08:22 and how apps handle it Feb 21 22:08:25 gnuconfigure just ignores anything after linux-gnu Feb 21 22:08:37 we've built world with it and not had any configuration problems Feb 21 22:08:42 (other then the siteinfo being wrong) Feb 21 22:09:33 ok thats better Feb 21 22:10:42 I think we should think of multilib Feb 21 22:10:44 mips Feb 21 22:10:53 that is how we're using it Feb 21 22:10:57 and start supporting mip64 in oe-core Feb 21 22:11:10 tri-lib.. mips + mips64-n32 + mips64 Feb 21 22:11:14 with mips64-n32 being the default Feb 21 22:11:29 yes thats the way it should be Feb 21 22:11:51 and I would go a step further and choose mips64 as default Feb 21 22:12:10 binaries are significantly larger and require more memory.. Feb 21 22:12:11 are you going to put forward those patches to oe-core Feb 21 22:12:23 most of our customers want mips64-n32 as the default, unless they are doing routers.. Feb 21 22:12:31 :) Feb 21 22:12:33 khem, we have pushed all of our patches back to make it work.. we don't use the OE compilers Feb 21 22:13:15 (well they were all pushed as of Monday.. I haven't checked today if we have some straglers) Feb 21 22:13:45 does that mean we changed default mips arch in oe-core now ? Feb 21 22:14:08 that is up to the BSPs... Feb 21 22:14:20 (I'm also not sure if oe-core has tunings for mips64) Feb 21 22:14:39 our MIPS64 boards though have multilibs enabled, as I mentioned before.. n32 being the default tune Feb 21 23:36:50 i noticed that for some machines, the images generate .sdcard image files. when I dd them to an sdcard and boot, I only have ~80 MB free space, even though the card has at least 3 GB unallocated space. Feb 21 23:38:04 is there a way to make an sdcard image which makes better use of the sdcard's capacity? is it possible to do that without artificially inflating the .sdcard file to several gigs? (using ext3 as root FS and FAT32 for the boot FS) Feb 21 23:41:41 at least one of the classes / scripts i've seen used sparse files Feb 21 23:41:51 afaik thats the best way to handle that Feb 21 23:42:04 you get a 4gb or whatever image without actually taking up tha tmuch disk space physically Feb 22 00:23:57 I keep thinking I've done this before, but I can't find it. Feb 22 00:24:21 I would like to suggest a change to bitbake's build scripts, which is to emit some kind of explanation of why they exit if they exit due to a failing command. Feb 22 00:26:46 seebs: you have done it before, we talked about it at one point, https://gist.github.com/kergoth/3885825 has bits from your bitbake patch for it Feb 22 00:26:56 i think thats what you're referring to, anyway Feb 22 00:26:58 Oh, good, I'm *not* going crazy. Feb 22 00:27:38 about this, anyway :) Feb 22 00:27:57 I just ran into this, we have a handful of build failures wherein the sum total of diagnostic output is "Error during do_rootfs, see log file". And that's all the log file has, too. Feb 22 00:28:45 And I was thinking "I totally thought I did something about this, but I can't find anything". Feb 22 00:28:52 * kergoth nods Feb 22 00:29:02 ... I was looking on the oe-core list, of course. Not the bitbake list. Feb 22 00:29:04 not sure wher the bitbake patch is, could be an rc on the list Feb 22 00:29:07 heh, oops Feb 22 00:29:45 Okay, apparently I sent out a proposed patch in October, and then never followed up on it. Feb 22 00:33:13 I really hate set -e. I mean, yeah, I get the intent, but in practice it's frequently.... not really what I want. Feb 22 00:53:11 agreed Feb 22 00:53:33 it's often just an excuse to be lazy with your error handling, and as in this case, when it does error out, often you dont know where or why Feb 22 00:54:04 and if you do need to use the output of a command that can fail, your'e stuck doing lame stuff like ret=0; foo || ret=$?; or whatnot Feb 22 00:54:17 s/output/exit code/ **** ENDING LOGGING AT Fri Feb 22 02:59:58 2013