4945 2013-07-29 12:46:27 +0000 No proper message in case of errors when building u-boot through bitbake 2013-08-09 15:34:58 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED Medium normal 1.5 1 lpapp ross.burton bluelightning jefro meta.mr.watcher meta.watcher ross.burton sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 35086 0 lpapp 2013-07-29 12:46:27 +0000 While running the following command: "bitbake u-boot" or "UBOOT_MACHINE=omap3_beagle_config bitbake u-boot" .. getting the following error message: ERROR: Nothing PROVIDES 'u-boot' ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ========================================== This is unclear for a newcomer due to the following reasons: 1) Not sure if UBOOT_MACHINE is supported or just the syntax is wrong somehow. 2) As it turns out "MACHINE=beagleboard bitbake u-boot" or similar kind should be passed, but I would have never guessed that as a newcomer. The suggestion is simply the addition or proper error diagnostics. Some reference should be taken to MACHINE rather than just UBOOT_MACHINE. That would clear up the situation right off-hand. 35087 1 bluelightning 2013-07-29 12:55:35 +0000 UBOOT_MACHINE can't be set externally because it's not in BB_ENV_EXTRAWHITE and it is not appropriate to add it there. It should be set to an appropriate value from your machine configuration file. Bottom line is you can't build u-boot for a machine that doesn't support it, and qemuarm doesn't. The recipe cannot tell which MACHINE will support it, only that UBOOT_MACHINE hasn't been set in the current configuration, which is exactly what it reports. 35089 2 ross.burton 2013-07-29 12:57:32 +0000 I'd say the best we could have is the error message to say "because UBOOT_MACHINE is not set, verify your machine configuration". 35090 3 lpapp 2013-07-29 13:02:18 +0000 No no, you misunderstood the report! It should say: "MACHINE is not set" or something similar. The very least, it should say "UBOOT_MACHINE, nor MACHINE" or so. Please be supportive with users, not reluctant. 35092 4 lpapp 2013-07-29 13:03:15 +0000 Giving errors about UBOOT_MACHINE, when the real issue is the MACHINE not specified is well... highly misleading to a user. 35094 5 lpapp 2013-07-29 13:05:05 +0000 Also, "qemuarm" was not mentioned in the report at all, but beagleboard, so please stay more on topic and focus on the issue at hand. 35095 6 bluelightning 2013-07-29 13:07:35 +0000 MACHINE *is* specified; so it not being specified is not the problem. If it were not qemuarm then some other machine configuration where UBOOT_MACHINE hasn't been set. We'd take a patch to change it as Ross suggested. 35096 7 lpapp 2013-07-29 13:10:25 +0000 Sorry, but you do not make any sense. There was *** NO *** any note about qemuarm, okay? There was not any. However, there was this mentioned because you are so attached to the outside world than this report, I have to repeat: "bitbake u-boot" or "UBOOT_MACHINE=omap3_beagle_config bitbake u-boot" I started with the first *** without *** MACHINE, okay? 35097 8 bluelightning 2013-07-29 13:14:06 +0000 MACHINE is set. It's set by default in your local.conf, so it doesn't matter whether you supply it on the command line or not. 35098 9 lpapp 2013-07-29 13:16:03 +0000 Then, of course it should report that. "MACHINE=... blabla specified not supporting this". At any rate, the user experience is fully broken. 35100 10 lpapp 2013-07-29 13:25:33 +0000 It should also mention that where it is specified exactly, so a file name for instance to make it explicitly clear as much as possible. 35101 11 lpapp 2013-07-29 13:32:37 +0000 That would be more explicit than this: "because UBOOT_MACHINE is not set, verify your machine configuration" What does it mean machine configuration? UBOOT_MACHINE in the config? MACHINE in the config? UBOOT_MACHINE, MACHINE, or even something else on the command line? "machine configuration" is a vague term, so I do not support that suggestion. It should be as explicit as possible. 35102 12 ross.burton 2013-07-29 13:46:09 +0000 http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-newmachine-conffile "Machine configuration" isn't a vague term, it's a specific file. 35103 13 lpapp 2013-07-29 13:48:25 +0000 Except that it does not tell anything specific to a newcomer without a lot of investigation on the topic. Just be cool and provide error message for end users, not hard code developers. :) The whole point is machine in this case anyway, and its validity after all, not the whole machine configuration anyway. 35182 14 sgw 2013-07-30 19:31:59 +0000 To ensure we are not vague in the error message, we can say the following: ERROR: u-boot was skipped: because UBOOT_MACHINE is not set in the ${MACHINE} machine configuration file, please verify your configuration" Where ${MACHINE} will be the setting of MACHINE It's not easy to identify the location of where MACHINE might be set, but one can use bitbake -e <target> to determine that. 35242 15 sgw 2013-08-01 06:26:52 +0000 See previous comment 35246 16 lpapp 2013-08-01 06:43:08 +0000 local.conf != command line. 35248 17 lpapp 2013-08-01 06:46:18 +0000 As I said, it is not proper. When the machine does not support u-boot, it should just tell that up front by also mentioning the selected machine. UBOOT_MACHINE is a red herring in case of qemuarm. 35251 18 ross.burton 2013-08-01 09:08:57 +0000 Patch sent that implements what Saul said. 35255 19 lpapp 2013-08-01 10:33:21 +0000 Then please open a bugreport for that. I am not asking that in this bugreport. Also, as written several times already, *please* post the links on bugzilla. Please be concerned about quality here, too. 35256 20 lpapp 2013-08-01 10:36:15 +0000 Please do not change the status to review if it implements a different request; thank you for your understand. I appreciate your work, but if it is a different request, then it is a different request, and hence "review" would be incorrect. 35257 21 ross.burton 2013-08-01 10:38:19 +0000 Then I clearly don't understand your original request. Please explain clearly and concisely, in pseudocode if possible, exactly what it is that you are requesting and explain how my patch doesn't implement it. As far as I can understand the patch I've sent is the best that is possible, so marking as in review. 35259 22 lpapp 2013-08-01 10:39:39 +0000 ok, you won the ping-pong game. As for the change ... you have not even bothered to paste a link even requested ... 35260 23 ross.burton 2013-08-01 10:44:46 +0000 I'm genuinely curious as to why my patch doesn't implement what you want, this wasn't some game for me. For looking up patches I recommend the patchworks service. http://patches.openembedded.org/patch/54893/. 35504 24 ross.burton 2013-08-08 17:09:01 +0000 Resolving fixed, the patch has been integrated into oe-core (beef66beaee926ec3d3640b79133fdb2ccc404f0) and no further improvements have been suggested. 35505 25 lpapp 2013-08-08 17:10:11 +0000 Actually, I have had suggestions on the mailing list which seems to have been ignored. :/ 35507 26 ross.burton 2013-08-08 17:16:40 +0000 One suggestion was along the lines of "I would like it to be more specific." There's a balance between concise and verbose, and listing the full path to all of the files that are involved in the machine configuration pushes too far into verbose for my liking. We state the machine name, so worst-case it's a find command to find the right initial configuration file. The other suggestion was along the lines of a warning when a variable is set in the environment. That's a valid use-case so we don't want to warn there. 35522 27 lpapp 2013-08-08 20:05:32 +0000 1) Why would everyone ever use find and similar stuff when it can return the very only file at hand right away? I am not even sure what "all the files" you are referring to. 2) Do you seriously think it is a normal and intended situation if a user sets the machine to foo when it is already foo in the background? That seems pointless to me, and it is very likely that is not what the user wanted, i.e. we should warn.