**** BEGIN LOGGING AT Fri Dec 13 03:00:00 2013 Dec 13 03:13:42 this looks odd... http://paste2.org/z0YemXd1 Dec 13 03:15:11 this one looks like it requires a clean rebuild, although i'm not sure why Dec 13 03:15:48 i had a full build already before i changed the gcc config Dec 13 03:59:02 * nerdboy wonders why a fresh build would have any do_populate_sysroot_setscene tasks in the first place Dec 13 03:59:33 that was the previous error, only now it's just a warning Dec 13 07:10:55 I have one doubt regarding princ value Dec 13 07:11:36 I have one bbappend file where i have making use of files placed in file folder Dec 13 07:12:18 now current value of princ is 4 and I have made some changes to one of file placed in file folder Dec 13 07:12:48 then in this case do I have to increment the princ value IN bbapend? Dec 13 08:56:32 good morning Dec 13 09:30:25 hi i just try to connect my at91sam9g35ek board to ubuntu pc through gadget serial g_serial,but when i try to open minicom it shows minicom: cannot open /dev/ttyACM0: No such file or directory, but there is a file in /dev/ttyACM0, can you help me Dec 13 09:34:27 any idea Dec 13 09:36:08 linu: permissions? Dec 13 09:42:09 n01 it has full permission crwxr-xr-x 1 root dialout 166, 0 Dec 13 15:09 /dev/ttyACM0, but when i try to open minicom with ttyACM0 it freeze with "Initializing Modem" message Dec 13 09:43:08 are you root? try with 777 just to be sure Dec 13 09:44:53 n01, crwxrwxrwx 1 root dialout 166, 0 Dec 13 15:12 /dev/ttyACM0 and when i try to open it shows me Device /dev/ttyACM0 is locked. Dec 13 09:48:15 locked? do you have other minicom sessions open? Dec 13 09:49:29 n01, yes ttyUSB0 for debugport. Dec 13 09:50:27 close all the minicom session and try to just open a new connection an ACM Dec 13 09:52:02 n01, yes i already tried that and even i reboot my pc,but it freeze with "Initializing Modem" message, now i opened only one session for ACM0, it freeze does not open Dec 13 09:55:52 Hi all...is there a specific way to integrate "Linux kernel backports" in "recipes-kernel" ??? Dec 13 10:00:17 n01, any idea Dec 13 10:00:21 morning all Dec 13 10:03:57 OlivierG: hi... not sure I understand the question... ? Dec 13 10:05:06 linu: check modemmanager or some other process is not using the port (lsof /dev/ttyACM0 should tell you) Dec 13 10:06:43 bluelightning: :)... i m using a kernel 3.10...but i need to integrate some external/backported drivers (iwlwifi) from a different directory ... Dec 13 10:07:47 OlivierG: well, it depends on what you mean by "integrate"... you should be able to build out-of-tree modules fairly easily using a separate recipe if that's what you're after Dec 13 10:07:51 bluelightning, please see http://pastebin.com/L7dAynMY Dec 13 10:08:20 linu: er, so you have another minicom session? or this is the one you just started? Dec 13 10:09:32 bluelightning: ok..so there's no "official" way to integrate drivers from http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ ... i ll do my recipe ;) Dec 13 10:10:30 bluelightning, actually i opened one session but i closed that now i have only one session,please see dmesg http://pastebin.com/JPs54U8f Dec 13 10:11:11 OlivierG: so what are these backports? patches on top of old kernels? Dec 13 10:11:30 OlivierG: I've never heard of this particular project but then I'm no kernel expert Dec 13 10:12:06 linu: no idea, sorry Dec 13 10:13:01 bluelightning, it is ok thanks Dec 13 10:16:09 bluelightning: i thought it was something done is the past.... never mind...i will dig in recipes ... anyway, thanks ! Dec 13 10:18:31 OlivierG: hmm. i never heard about that too. that sounds interesting. Dec 13 10:18:52 OlivierG: what does it build eventually? a new kernel image? or .ko files? Dec 13 10:20:00 bluelightning: For me, i would like to build new .ko , as i want "bug-less" wifi driver Dec 13 10:21:44 well, i am familiar with compat-wireless, this thing seems to be an extension of that project. Dec 13 10:28:27 ndec: you are right... i want to use the tree "as-is"...so i need to DL the whole file, unpack it, do a "menuconfig", build the whole tree and copy the .ko to my "official" kernel working dir... Dec 13 10:31:44 OlivierG: does it have to go to the kernel working dir or can it be packaged separately? see meta-skeleton/recipes-kernel/hello-mod/ for an example Dec 13 10:32:47 bluelightning: the instructions seem to say that you need to 'point' to the kernel dir, but not be inside it. like kernel modules. Dec 13 10:33:20 but module.bbclass wouldn't be enough, since this backport stuff needs to run some menuconfig things, unlike modules Dec 13 10:34:35 It is very similar to a kernel build process... Dec 13 10:35:06 hmm, I see Dec 13 10:35:40 you'd need to do that in the context of the kernel recipe then; the kernel sources (other than the headers) won't be available outside of there Dec 13 10:36:42 hmm, i thought we had all sources in STAGING for the kernel. Dec 13 10:38:56 bluelightning: we do keep a copy of all kernel sources: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/kernel.bbclass#n223. no? Dec 13 10:39:25 ndec: hmm, I stand corrected Dec 13 10:39:49 ;-) Dec 13 11:05:34 ndec: did you look at http://layers.openembedded.org/layerindex/recipe/6980/ ? ... it is quite old ... Dec 13 11:06:08 no. when i had used compat-wireless it was not with OE. Dec 13 12:59:46 -c devshell opens a shell window for me but i get no cursor, can not type anything, i can only press enter and a new line appears. any pointers on how to fix this? Dec 13 13:00:24 Denwid: which host distro are you using and which terminal is being launched? Dec 13 13:01:22 bluelightning: Using debian 7 and with kde but gnome shell is being launched Dec 13 13:02:47 I did try to set TERMCMD='konsole -T' in local.conf but it's still opening gnome-shell Dec 13 13:47:58 Denwid: unfortunately konsole won't work, see bug 4934 Dec 13 13:47:59 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4934 enhancement, Low, Future, paul.eggleton, NEW , Make konsole work with KDE 4 for OE_TERMINAL Dec 13 13:48:05 Denwid: I'm also a KDE user, FWIW Dec 13 13:48:30 I use OE_TERMINAL = "screen" here Dec 13 14:25:24 hi there, I have defined IMAGE_ROOTFS_SIZE in my image recipe Dec 13 14:25:31 now I'd like to override it from conf/local.conf Dec 13 14:25:47 is it just about assigning this variable second time in local.conf? Dec 13 14:34:58 Xz: if the image recipe sets it with = you can't use = to set it from local.conf, because the image recipe is parsed last Dec 13 14:35:55 Xz: either the image recipe should set it with ?= or you'll have to use hacks such as using an override in the local.conf setting (e.g. IMAGE_ROOTFS_SIZE_forcevariable = "123456") Dec 13 14:37:03 but note of course that setting IMAGE_ROOTFS_SIZE from local.conf will apply to *all* images you build, not necessarily just the one you want Dec 13 15:02:46 bluelightning: ok, got it, thanks Dec 13 15:19:03 morning Dec 13 15:28:52 Hello, good afternoon. Dec 13 15:30:47 kergoth: have you tried the sourcery toolchain? Dec 13 15:32:58 yeah, but I didn't hit your failure :\ Dec 13 15:33:13 used poky master and meta-sourcery master, with a freshly unpacked tarball of the toolchain you linked Dec 13 15:33:32 i hit a compile error in libffi, which we have a patch for lurking in meta-mentor Dec 13 15:33:32 kergoth: that git relocation fix looks nice, thanks ;) Dec 13 15:33:48 :) Dec 13 15:34:03 kergoth: :-( Dec 13 15:34:04 Too bad more upstream projects don't care about such things Dec 13 15:37:48 kergoth: anyway, now I'm trying to make an image for a mips32 little endian, using the yocto toolchain, and I have the same problem as I had few days before. When it tries to build the kernel, it fails due to "ERROR: QA Issue: Endiannes did not match". I really don't need the kernel, I just want the rootfs. So..., how can I disable the kernel? Dec 13 15:47:10 vicenteolivert: images often include kenrel modules, etc, so it's usually not as simple as just "disabling" the kernel Dec 13 15:47:25 I don't need kernel modules either. Dec 13 15:47:48 but that doesn't mean there aren't things that depend on or recommend the kernel module packages Dec 13 15:47:52 kergoth: but the kernel fails to build and stops the process, so my rootfs is built either. Dec 13 15:48:10 *is not built either Dec 13 15:48:21 I understand that, I'm just pointing out that the kernel isn't pulled into the build by just one thing in just one place Dec 13 15:48:46 Uhm... Dec 13 15:49:03 I'll try to find which things need kernel modules and try to remove from my target. Dec 13 15:49:21 if nothing tries to pull it into the image, you could try to hack it out with ASSUME_PROVIDED, or it's possible you might be able to use the dummy kernel recipe, but i've never tried either, unfortunately. lperhaps someone else in here will know offhand Dec 13 15:52:32 kergoth: uhm..., that sounds good. Dec 13 15:53:16 kergoth: how can I do it with ASSUME_PROVIDED? Just add ASSUME_PROVIDED = "" Dec 13 15:53:21 Sorry. Dec 13 15:54:04 ASSUME_PROVIDED += "virtual/kernel" would tell bitbake it's already there, so don't try to build it, but if anything tries to pull anything from that build in, things will understandably explode. another option would be to try PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Dec 13 15:54:27 Ok, let's try it! :-D Dec 13 15:54:33 Thanks kergoth . Dec 13 15:54:50 np Dec 13 15:56:05 morning kergoth Dec 13 15:56:22 kergoth: Ok, I think oprofile recipe is the one who is pulling in the kernel. Dec 13 15:56:41 Hello bluelightning, how are you? :-) Dec 13 15:58:38 hi vicenteolivert Dec 13 15:58:44 vicenteolivert: great thanks, and you? Dec 13 15:59:23 bluelightning: I'm fine too, trying to get Yocto working :-P Dec 13 16:04:16 https://wiki.yoctoproject.org/wiki/Yocto_1.6_Schedule Dec 13 16:06:24 Song_Liu: just noticed the 'release date' at the top (section 2) is wrong Dec 13 16:06:31 everything else looks fine Dec 13 16:06:38 I can use IMAGE_INSTALL += "package_name" to install a package in my target, but..., how can I avoid the installation of a package? IMAGE_INSTALL -= "pacakge_name" doesn't work. Dec 13 16:07:04 vicenteolivert as long as you are using 'dora' or master.. PACKAGE_EXCLUDE = "package_name" Dec 13 16:07:14 NOTE, if something else in the system requires that package, you -will- get an image failure.. Dec 13 16:07:15 Ahhh, PACKAGE_EXCLUDE. Dec 13 16:07:28 so you will end up having to add more and more stuff to the exclusion list until you get what you want Dec 13 16:07:31 Sometimes is difficult to remember all the things you have read in the manual. Is very big. Dec 13 16:07:50 fray: ok, thank you! Dec 13 16:09:08 no problem Dec 13 16:27:27 No luck, unfortunately. Do you know how to get rid of this error? http://pastebin.ca/2497906 Dec 13 16:28:11 vicenteolivert: do you have PREFERRED_PROVIDER set? Dec 13 16:28:31 sgw_: PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Dec 13 16:28:44 I don't want to compile the kernel, only the rootfs. Dec 13 16:28:58 Because the kernel compilation fails. Dec 13 16:29:55 hmm, can you verify that with the bitbake -e | grep "^PREFERRED_PROVIDER_virtual/kernel" Dec 13 16:30:44 sgw_: empty output. Dec 13 16:32:05 vicenteolivert: because it's erroring out not a warning, sorry yeah it would be empty., where are you setting that? Dec 13 16:32:26 sgw_: in the config/local.conf file. Dec 13 16:35:29 vicenteolivert: are you on master or dora? I just tried to set it in my local.conf file and no problem Dec 13 16:36:56 sgw_: honestly, I don't know. I cloned the git repository. Dec 13 16:37:22 sgw_: meta-yocto-bsp = "maste:..." Dec 13 16:37:28 *master Dec 13 16:37:40 vicenteolivert: that would be master then since you cloned head, can you pastebin your local.conf please Dec 13 16:37:56 sgw_: of course. Dec 13 16:39:37 sgw_: http://pastebin.ca/2497907 Dec 13 16:42:56 vicenteolivert: looking, I thought maybe the ASSUME_PROVIDED was causing problems but I just tried a bitbake -e core-image-minimal with your local.conf and it worked! Dec 13 16:43:46 sgw_: yes, core-image-minimal doesn't need the kernel. It builds it at the end and the rootfs is already created. Dec 13 16:44:17 But with core-image-minimal I can't have a console, just boot the kernel and that's all. Dec 13 16:44:22 vicenteolivert: So what target are you using that fails? Dec 13 16:44:35 What's why I'm trying core-image-base Dec 13 16:44:52 Ok trying Dec 13 16:45:07 The problem is, for little endian the kernel fails to build. The packages build ok, only the kernel fails. Dec 13 16:45:08 And with bigendian there is no problem. Dec 13 16:45:32 But the board I'm going to put the rootfs is little endian, so... Dec 13 16:46:16 And I'll compile my own kernel from another sources, so, I don't care about the yocto kernel. That's why I was trying to get rid of it. Dec 13 16:48:15 sgw_: is putting DEFAULTTUNE = "mips32el" in local.conf the right way to choose the target architecture? Dec 13 16:48:31 vicenteolivert: I understand what you are trying to do, I am trying to reproduce your failure to try and help, but I can't seem to reproduce the failure Dec 13 16:48:58 sgw_: you need to wait until linux-yocto is being compiled. Dec 13 16:49:27 Can happen at task >1000 of ~3000, Dec 13 16:51:46 sgw_: how have you created the bsp? Dec 13 16:52:32 yocto-bsp create mips Dec 13 16:53:37 vicenteolivert: yes I think setting DEFAULTTUNE is correct, i have not used that tool Dec 13 16:54:31 vicenteolivert: I would expect the error you posted right away during recipe parsing, which is why you are not getting any output from bitbake -e Dec 13 16:55:16 sgw_: yes, that error appeas at the beginning, but the compilation starts anyway. Dec 13 16:55:51 *appears Dec 13 17:06:20 vicenteolivert: I know about that error, but I am not able to reproduce it so there might be something else wrong in your env Dec 13 17:06:52 vicenteolivert: are you using a bsp generated by the create-bsp script? Dec 13 17:07:14 yocto-bsp create mips Dec 13 17:07:19 I use that. Dec 13 17:09:45 vicenteolivert: hi, re yocto-bsp, when run it, it gives you the option to use a custom kernel, is that what you chose? Dec 13 17:10:25 tomz1: no, I choose the option #6, I don't remember the name, but it's something about tiny. Dec 13 17:11:42 tomz1: I would like that yocto-bsp give me the option "no kernel, only rootfs" xD Dec 13 17:12:02 vicenteolivert: sounds like you wanted a non-yocto kernel, which would be custom (#8) Dec 13 17:12:34 tomz1: no, I don't want any kernel at all. Dec 13 17:12:34 And no modules. Dec 13 17:12:36 Just the rootfs. Dec 13 17:13:57 tomz1: if I choose a custom kernel, I think it will fail again because the problem is it can't be build on little endian, I don't know why. Dec 13 17:13:57 With big endian builds perfectly. Dec 13 17:14:13 vicenteolivert: hmm, no kernel, yocto-bsp doesn't have that option - dunno what you'd need to tweak off the top of my head, but i think i've seen someone trying to do that on the list, maybe check there, or maybe someone else would know that Dec 13 17:14:56 tomz1: I'm new to Yocto. Is there another way to generate my rootfs without using yocto-bsp> Dec 13 17:14:58 ? Dec 13 17:16:46 yocto-bsp just creates a layer for you, nothing special about it - sounds like you need to tweak an image recipe to get rid of the dependency on the kernel Dec 13 17:18:21 vicenteolivert: maybe try to create an image that doesn't include 'DEPENDS = "virtual/kernel" Dec 13 17:19:43 tomz1: well..., I tried core-image-minimal, and I had luck because the kernel is built at the end, in the last task, so the rootfs is already created. It fails anyway, but I get my rootfs :-) Dec 13 17:19:51 But now I can't use that trick. Dec 13 17:21:42 vicenteolivert: I noticed you set MACHINE=qemumips, do you override that to your bsp? Did you include your bsp layer in bblayers? Dec 13 17:21:55 vicenteolivert: i guess something pulled in by core-image minimal is pulling it in via its dependendencies, you'd have track that down Dec 13 17:22:22 sgw_: I haven't touched the bblayers.bb file. Dec 13 17:22:46 bblayers.conf, sorry. Dec 13 17:23:44 vicenteolivert: Ok then you are not really using what was created by yocto-bsp then, red-herring sorry to bother you tomz1, thought it might have been some config you had created. Dec 13 17:24:13 sgw_: now I have added my layer before the meta layer in bblayers.conf Dec 13 17:25:00 vicenteolivert: wait! I want to stay with known issues rather than adding new issues. Dec 13 17:25:11 * kergoth chuckles Dec 13 17:25:23 Ooops. Ok sgw_ . Dec 13 17:25:24 kergoth: thanks for the encouragement! Dec 13 17:25:29 :) Dec 13 17:26:04 Ok, I have removed everything. I'm going to start from the beginning. Dec 13 17:26:17 I have the feeling that something is not clean... Dec 13 17:26:33 RP: Any objection to adding a backfill for PACKAGECONFIG? Dec 13 17:26:48 that's my guess also, if you do a git status in your clone any change? Dec 13 17:27:16 RP: I was wanting to add a packageconfig for systemd to allow disabling of sysvinit compat mode, but don't want to screw up folks with existing PACKAGECONFIG_pn-systemd values Dec 13 17:27:32 RP: which is a perfect case where a backfill would be ideal Dec 13 17:27:54 poky $ git status # On branch master nothing to commit, working directory clean Dec 13 17:28:08 sgw_: nothing. Dec 13 17:28:22 kergoth: I just worry about the extra code. The metadata is getting ever more complex and this just continues that trend :/ Dec 13 17:28:40 kergoth: In some ways I'd prefer a layer version number and migration code Dec 13 17:29:06 well, implementation wise it's just a single function call, but it will add yet another variable for recipes that use it, sure Dec 13 17:29:12 kergoth: people also got confused about the distro backfill mechanism Dec 13 17:29:49 vicenteolivert: Ok, so nothing there, you local.conf file is pretty generic, try removing that ASSUMED_PROVIDED line, it does not really make sense as it stands. Dec 13 17:30:12 vicenteolivert: then run a bitbake -e and see what we get Dec 13 17:30:34 while we do have layer version numbers, we don't really have a way to say this layer version is incompatible with anyone that depended on the previous version Dec 13 17:30:38 afaik anyway Dec 13 17:32:39 kergoth: no :/ Dec 13 17:32:58 sgw_: I remove the ASSUMED_PROVIDED but I leave the PREFERRED_PROVIDER? Dec 13 17:32:59 we sort of do, layers can specify a dependency on a specific version Dec 13 17:33:09 vicenteolivert: yes Dec 13 17:33:25 but the layer version stuff has been co-opted for AB-breaking changes which is not the same as some of the other changes we're wanting to capture Dec 13 17:33:50 sgw_: and run "bitbake -e", without the core-image-basic? Dec 13 17:33:51 and, nobody uses the versioned dependencies it anyway (AFAIK) Dec 13 17:34:14 vicenteolivert: sorry bitbake -e core-image-basic Dec 13 17:34:29 Ok, doing it right now. Dec 13 17:36:04 sgw_: I obtain an output of 19203 lines. Dec 13 17:36:40 vicenteolivert: yes it's kind of verbose, but very help debugging into, do you did not get the ERROR this time? Dec 13 17:37:03 sgw_: yes, I don't have the error because we have removed the PREFERRED_PROVIDER. Dec 13 17:37:19 Now I only have a note: NOTE: consider defining a PREFERRED_PROVIDER entry to match kernel-base Dec 13 17:38:32 vicenteolivert: I thought you left PREFERRED_PROVIDER, not remove it. Dec 13 17:38:54 Sorry. Dec 13 17:39:04 sgw_: yes, I don't have the error because we have removed the ASSUMED_PROVIDED. Dec 13 17:39:08 :-P Dec 13 17:39:14 Yup, that was it. Dec 13 17:40:08 sgw_: but I think I will have the same problem. If linux-yocto is pulled in, it will fail to compile, and I will not obtain my rootfs. Dec 13 17:41:30 The next step is "bitbake core-image-base", or do you want to try something first, sgw_? Dec 13 17:42:11 vicenteolivert: if PERFERRED_PROVIDER is set to linux-dummy then I think it will continue (I have not built with linux-dummy), your correct, try that build. Dec 13 17:44:02 vicenteolivert: only step is to confirm that PREFERRED_PROVIDER_virtual/kernel is set to linux-dummy from the output of the -e command Dec 13 17:44:05 Inside build/meta-urboard/conf/machine I have a file called urboard.conf (urboard is the name I have used to create the BSP with "yocto-bsp create"). In that file there is all the kernel related things. Dec 13 17:45:58 $ grep PREFERRED_PROVIDER_virtual/kernel output # $PREFERRED_PROVIDER_virtual/kernel [2 operations] PREFERRED_PROVIDER_virtual/kernel="linux-dummy" Dec 13 17:48:34 Ok, I'm running "bitbake core-image-base" now. I hopw it works... I'll check it on monday because it's late and I have to go home. Dec 13 17:49:05 sgw_, kergoth, tomz1: thanks for you patience, time and help. Dec 13 17:49:23 See you on monday. Have a nice weekend. Bye! Dec 13 17:49:43 vicenteolivert: have a good weekend Dec 13 18:28:12 Hello. Anyone familiar with the qt bb recipes and why they apprently fail to build WebKit without the HOST system having them installed? Dec 13 18:31:49 WarheadsSE: qt4 or qt5? Dec 13 18:31:57 qt4 Dec 13 18:32:24 I'll be messing with qt5 soon enough to handle the native-sdk generation, but right now qt4 Dec 13 18:56:29 bluelightning: any reason in particular for that ? Dec 13 18:56:56 WarheadsSE: that's not expected, it sounds like a bug Dec 13 18:57:50 WarheadsSE: when you say "them installed" by them do you mean webkit itself? Dec 13 18:58:42 Yeah, seems if QtWebKit headers are installed on the host, it will generate in bitbake Dec 13 18:58:49 if NOT, then it will not exist. Dec 13 19:09:05 WarheadsSE: hmm OK, I will try to reproduce next week... in the mean time if you could file a bug in our bugzilla that would be very much appreciated Dec 13 19:09:12 * bluelightning heads out Dec 13 22:03:57 libffi is in recipes-gnome? Dec 13 22:04:00 * kergoth scratches head Dec 13 22:11:23 hi kergoth Dec 13 22:32:37 so i rebuilt fresh with java,fortran last night, so it should be possible to build a fortran package Dec 13 22:34:26 LetoThe2nd: let me know if you got any farther Dec 13 22:35:06 especially if you have a working recipe of something R-related... Dec 13 23:09:11 I've been re-reading the Yocto docks, especially the quick start guide; and, it suddenly dawned upon me that most of that guide is totally redundant, and in fact flies in the face of what Yocto is all about. Dec 13 23:10:14 I take for example the instruction to download various utilities including awk make wget tar bzip2 gzip python unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ ccache perl-Data-Dumper perl-Text-ParseWords SDL-devel xterm Dec 13 23:10:38 Why isn't there a Yocto recipe to do all that ? Dec 13 23:11:45 I guess I would require, as a prerequisite, wget. After that, all the other dependencies could be satisfied by Yocto itself. Or perhaps, I'm missing something Dec 13 23:15:18 When I encounter these issues, it make me really question the calibre of the people writing the docs, and contributing to Yocto. Please tell me I'm wrong. I'd like to believe that Yocto can help me with my project. But as it is, what I see is a bunch of muddled thought, solving a problem that only exisits because other people like the Yocto contribs can't think clearly. Dec 13 23:15:18 yocto doesn't know how to interface with your build machine's toolchain Dec 13 23:15:24 also, how would it build gcc without gcc? Dec 13 23:15:29 a c ertain amount is necessary to bootstrap regardless Dec 13 23:15:36 er, your build machin'e spackage manager, i meant Dec 13 23:15:44 so yes, you're missing something :) Dec 13 23:16:10 Sure. So, that should be resolved by Yocto - at least for standard distros Dec 13 23:16:12 I don't think insulting the hundreds and more folks working on the project is a way to move forward or address your misunderstandings Dec 13 23:16:47 I'm not insulting anyone Dec 13 23:17:02 I'm trying to force clarity Dec 13 23:17:26 What is Yocto doing if it's not doing almost everything for me Dec 13 23:18:28 Most software has dependencies, and most software requires you to install those dependencies, unless they provide packages for your distro. yocto is no exception to that. and if you think there's no problem solved by yocto, you must be extremely new to embedded systems Dec 13 23:19:02 Whatever dependencies Yocto has should be resolved by Yocto Dec 13 23:19:20 Other than an absolute minimum Dec 13 23:19:35 Like wget Dec 13 23:19:40 and perhaps make Dec 13 23:19:48 even that is questionable Dec 13 23:20:07 further, considering there are plenty of other projects competing with bitbake/oe/yocto that do similar things, all to try to resolve similar problems, it's pretty ridiculous to claim there's no problem they solve Dec 13 23:20:27 * kergoth /ignores and moves on with real work Dec 13 23:24:15 I'm just trying to understand the whole picture. What we seem t have is a half baked system. BUT a really necessary system. I just want to understand it completely. And during my learning process, if I find something that seems wrong, I shouldn't be afraid to ask, at least. If you can't provide an answer, I gues sit means either the question is invalid, or there is no good answer. WHich one do you whish to admit to ? Dec 13 23:25:23 smartin, you are getting off to a really bad start in here Dec 13 23:25:57 urg Dec 13 23:26:01 I meant Smitty Dec 13 23:27:51 Perhaps Dec 13 23:28:27 I'm asking difficult questions perhaps Dec 13 23:30:11 I've aready tried Yocto, following the Quick Start Guide, and it failed to build a component, even though I am definitely running on a "Supported Linux Distributions" Dec 13 23:30:58 SO excuse me for being skeptical. Dec 13 23:33:57 I actually want it to work. I have a real need for such a tool. But having stumbled across Yocto, which claims to do thing that I have yet to see it do, I am, trying to figure out where my thinking is wrong, or perhaps, where the Yocto key contributors thinking is wrong. Dec 13 23:34:01 Smitty: Its a tricky problem to solve. Ok, you download some tarball with wget, ok you unpack it with tar, can you autoreconf it? no. ok, lets assume it doesn't need autoreconfing (many do due to bugs). You need to compile it. That needs make and gcc. Now we do build many native utilities ourselves but we do need something to bootstrap them Dec 13 23:35:09 Smitty: that list in the quick start is an all inclusive list. There are some which can be considered fairly optional. If you skip gcc-multilib for example, grub-native won't build Dec 13 23:35:26 Smitty: Its a list of things we can find on most desktop systems and assume to be sane Dec 13 23:36:05 Smitty: equally we build a buildtools tarball you can install on a system and have it provide many of the more problematic tools we need Dec 13 23:36:22 Smitty: "problematic" tools funnily enough include tar Dec 13 23:37:15 Excelllent. Now we're getting to the root of my question (possibly). And I don't mean to be so pedantic, but as programmers, we're all pedantic. Dec 13 23:37:23 Yes, excellent point. Dec 13 23:38:26 Smitty: I'm curious what failed to build for you? Dec 13 23:38:29 So, there is a small subset of tools needed for Yocto to be able to reasonably be expected to run Dec 13 23:39:24 I'm just re-running (for the third time) a totally clean build based upon the Quick Start guide. Dec 13 23:39:30 Smitty: we could try and bootstrap everything but at some point the build time becomes annoying and a bit pointless so we try and have a happy medium. The system can be tuned in either direction Dec 13 23:39:59 heck, we do move up and down that scale depending on which tools appear stable and which ones users report problems with Dec 13 23:40:02 I failed previousy on something to do with qemu Dec 13 23:40:19 Smitty: qemu-native? Dec 13 23:41:09 I was perhaps confused by the documentation, and after a IRC chat on this channel with kergoth (super helpful, BTW) I understood better what was going on Dec 13 23:41:25 Smitty: I have to admit that qemu-native is one of the only "floating" configuration packages we have since some people want graphics and some people don't so we let it autodetect Dec 13 23:41:47 There are changes in master recently to reduce the amount of floating Dec 13 23:44:08 Smitty: If it helps clarify, we never assume anything for the target is already provided, we always build all the target components (unless you configure it differently) Dec 13 23:46:10 I am now at task (191 of 5341): which eems to have been running for about 5 minutes Dec 13 23:46:43 Strange that my intel i5 would struggle so much for this Dec 13 23:48:07 Smitty: well, suggestions on how we speed up the system to perform better would be more than welcome Dec 13 23:48:33 Not my point at all. Dec 13 23:50:31 Smitty: which task is it on? Dec 13 23:50:43 Anyway. As I said, I'm working my way through the QUick Start guid for the 3 (or 4th) time, and have yet to get a completed build. You'll have to forgive my skepticisim Dec 13 23:50:53 218/5341 Dec 13 23:51:02 so, it is doing something Dec 13 23:51:16 Smitty: well, did you change anything between these runs? Dec 13 23:51:43 Yes. The only thing I didn't do this time was to change anything Dec 13 23:52:21 So, whatever is the default config for the downloaded recipe, I'm doing it Dec 13 23:52:41 Smitty: FWIW the system is pretty reproducible so if it failed last time and you didn't change anything I'm not optimistic it will do something different this time Dec 13 23:53:05 Smitty: If you shared how it failed, maybe someone could give better pointers to what might be wrong Dec 13 23:54:00 Last time I targetted x66, because I I couldn't understand what it meant to target a qemux86 Dec 13 23:54:06 x86 Dec 13 23:55:02 now I am simply letting the default (downloaded) config target whatever is already configured Dec 13 23:55:19 Smitty: I can see how that would break. I will pass that comment back to your tech writer Dec 13 23:56:01 Huh ? Dec 13 23:56:15 Why would targetting x86 fail ? Dec 13 23:57:18 Smitty: It means to set MACHINE to some value and only a certain set of values work for that option Dec 13 23:57:57 I am afraid you've lost me with that explanation Dec 13 23:58:18 Smitty: how did you target x86? Dec 13 23:59:10 By default, the target architecture for the build is qemux86, which produces an image that can be used in the QEMU emulator and is targeted at an IntelĀ® 32-bit based architecture. To change this default, edit the value of the MACHINE variable in the configuration file before launching the build. Dec 13 23:59:31 I read that and thought, WTF Dec 14 00:00:06 How can something target x86 and magically not target qemu which supports x86 Dec 14 00:00:40 so I changed the target to vanilla x86 Dec 14 00:01:07 Smitty: but is that 586? 686? P4? Dec 14 00:01:19 those aren't options Dec 14 00:01:41 Smitty: when you see architecture there its meaning more the target hardware configuration Dec 14 00:01:45 http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-MACHINE Dec 14 00:02:09 the target options are specified by the MACHINE variabel, right ? Dec 14 00:02:43 Smitty: it specified which piece of target hardware (or emulation) you want to use the output on Dec 14 00:02:54 Anyhow, I'm afraid I need to sleep Dec 14 00:02:58 'night! Dec 14 00:03:22 I quote the Quick Start Guide Dec 14 00:03:25 By default, the target architecture for the build is qemux86, which produces an image that can be used in the QEMU emulator and is targeted at an IntelĀ® 32-bit based architecture. To change this default, edit the value of the MACHINE variable in the configuration file before launching the build. Dec 14 00:04:19 valid values of MACHINE are provided in here http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-MACHINE **** ENDING LOGGING AT Sat Dec 14 02:59:59 2013