**** BEGIN LOGGING AT Tue Aug 20 02:59:59 2013 Aug 20 07:39:10 is there a way to completely reset a bitbake build? i just aborted one and cleared download/sstate afterwars, but now it seems to be confused Aug 20 08:11:22 LetoThe2nd: what do you mean by reset? Aug 20 08:11:56 you can either remove 'tmp' folder and keep download and sstate, that's generally enough. Aug 20 08:12:14 next step is to remove sstate too, and you pretty much restart from scratch. Aug 20 08:14:39 ndec: thanks *notes* Aug 20 08:16:32 LetoThe2nd: sometimes when doing 'dev' i end up with messing up the 'sysroot' folder, especially when editing/changing recipes. in that case removing 'tmp' is the right thing to do. Aug 20 08:16:48 ndec: ok.. think i get it (slowly) Aug 20 08:24:03 anyone know if there's some documentation on the nativesdk.bbclass (other than reading the bbclass :) )? Aug 20 08:24:35 Hello. I would like to add patches in a fixes layer (called meta-fixes) for dlt-daemon in meta-ivi. But bitbake only searches inside meta-ivi and in downloads.. Hence, it does find the bbappend, which lists the patches as part of the SRC_URI Aug 20 08:25:00 Can I append something to the search path? Aug 20 08:25:41 simon_b: yes, using FILESEXTRAPATHS_prepend Aug 20 08:26:12 erbo: thank you. How do I specifiy the bbappend' Aug 20 08:26:17 ..path? Aug 20 08:26:27 simon_b: look at e.g. recipes-core-ivi/eglibc/eglibc_2.18.bbappend Aug 20 08:27:32 thx Aug 20 08:27:35 the row FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" will make it look in the / for files Aug 20 08:28:42 simon_b: if it's a fix that affects everyone the meta-ivi maintainers are usually very helpful getting it fixed in meta-ivi Aug 20 08:49:37 * jeremiah lurks Aug 20 08:50:13 hey jeremiah! Aug 20 08:54:30 B4gder: Ohai! Aug 20 08:54:36 Good to know you're here too! Aug 20 08:54:58 Now I'm not as scared =D Aug 20 08:56:29 haha Aug 20 09:08:17 morning all Aug 20 11:32:04 when building kbd, i get "Exception: ExpansionError: Failure expanding variable SUMMARY, expression was ${SUMMARY} - Debugging files which triggered exception Exception: variable SUMMARY references itself!". i don't particularly mind if my distro doesn't have kbd; is there an easy way to tell bitbake not to include it in the image? Aug 20 11:32:35 Hi, i got a bootup problem, i generate an Image cpio.gz Image with "Intel Atom" and core-image-minimal-initramfs, then i copied it to a cf card with a syslinux bootloader, it boots up and Holds/Wait with follow Message "Waiting for removable media..." is there any special kind in syslinux to append the rootfs? Aug 20 11:33:25 as far as i can tell, the actual inclusion of kbd is several includes/inherits deep, so ideally i would like a way to say "don't build kbd even though it says you should", rather than having to edit some official bbclass Aug 20 11:34:16 daBONDi_work: does yocto generate a syslinux config for you, or did you have to do that manually? Aug 20 11:34:21 BCMM: this may sound odd, but try bitbake kbd -ccleanall and then try your build again Aug 20 11:34:33 BCMM: i've seen that error happen very rarely/randomly Aug 20 11:35:28 rburton: thanks, i'll try that Aug 20 11:35:51 bcmm: i build it manualy syslinux -i /dev... and make a syslinux config, LABEL xx kernel bzImage initrd ...gpio.gz Aug 20 11:35:56 rburton: in general, is there an easy way to just remove a package from my image, other than by modifying core classes or recipes? Aug 20 11:36:47 rburton: looks like that's working now, thanks. what's the diff between clean and cleanall? Aug 20 11:37:27 bcmm i think it removes the kernel file also and rebuild it Aug 20 11:39:53 BCMM: there's a way in development now, but sometimes if you can chase where the package is getting pulled in you can see a way to remove it Aug 20 11:40:10 ie kbd might be tied to "have a keyboard" machine feature Aug 20 11:40:26 rburton: huh, that's a pretty good idea actually Aug 20 11:40:36 it does have a keyboard, but i'm perfectly happy to just use the in-kernel keymap Aug 20 11:40:59 rburton: any idea how to do a build without udev? Aug 20 11:43:19 BCMM: meta/recipes-core/packagegroups/packagegroup-core-boot.bb defines VIRTUAL-RUNTIME_dev_manager ?= udev Aug 20 11:43:21 so you could change that Aug 20 11:43:36 i expect setting it to "" would let you use a static /dev Aug 20 11:43:49 (you can do that in your distro or local.conf) Aug 20 11:44:04 then you get to play the game of all the other things that also want udev ;) Aug 20 11:58:23 rburton: the client switch above was me losing electricy and moving to a phone, so I'll try stuff when it comes back. thanks. Aug 20 12:12:07 when i want to build a linux Image to run completly from ram the core-image-minimal-initramfs is the way to go right? Aug 20 12:12:33 or is it even possible to build it with yocto Aug 20 12:12:49 daBONDi_work: yeah, that works Aug 20 12:12:50 i use "debirf" before to shrink down a debian dist Aug 20 12:13:30 there's plenty of prior art for yocto-based products that are actually fairly large initramfs systmes Aug 20 12:14:13 i need a small x86_64 Image Aug 20 12:14:20 current my debirf image has 70 MB Aug 20 12:14:33 space is not so critical its running on an full blown intel atom Aug 20 12:14:39 with 2gb ram Aug 20 12:18:21 ok i think i found it why my image not booting on system with cf card Aug 20 12:18:28 CONFIG_PCMCIA in kernel config maybe missing Aug 20 12:19:07 daBONDi_work: that is exactly wthan I'm trying to do (run with only an initramfs) Aug 20 12:19:24 you got it to work ? :D Aug 20 12:19:46 daBONDi_work: still working on it, but kinda Aug 20 12:20:24 i've been using rpi-hwup-image from the unofficial raspberry pi bsp, then building an initramfs manually from the generated filesystem Aug 20 12:20:36 i trying realy hard to understand the yocto structure, but my brain don't get it :-) maybe my brain missing some prerequesites Aug 20 12:20:51 so far it requires manually disabling udev to boot Aug 20 12:21:36 maybe i should be basing what I'm doing on core-image-minimal-initramfs instead Aug 20 12:22:10 i guess i could still use the MACHINE from the pi bsp to get the right arm abi... Aug 20 12:22:36 so prbly i need a selfmade bsp depennding on atom-pc and add up "CONFIG_PCMCIA", back to the yocto docs :-) Aug 20 12:45:07 Hello everyone, I've been playing around with my own layers and after removing my layer from the bblayers.conf file bitbake seems to still include remnants from it in the build. I keep getting "ERROR: Nothing RPROVIDES 'hello' " Aug 20 12:46:37 cfo215: I think << yocto noob, make a bitbake -c cleanall Aug 20 12:47:04 should cleanup all prebuild packages and the sstate dir an rebuild all fresh Aug 20 12:47:12 no, that's not the problem here Aug 20 12:47:27 cfo215: you must still have a reference to "hello" somewhere in your configuration Aug 20 12:53:38 bluelightning: I'm reproducing it for you now. I'll paste it along with my notes. Aug 20 12:55:01 Kernel find now my cf Card and put it under hda1 but got still "Waiting for removable media" :-/ Aug 20 13:15:25 daBONDi_work: you will probably have to make your own init script Aug 20 13:16:34 mhh Aug 20 13:17:02 or your card is not getting correctly mounted Aug 20 13:17:41 the init script looks for rootfs.img in /media/*/ Aug 20 13:17:51 im currently crawling the meta\rec..-core\initrdscripts\files/init-live.sh, here it stands Aug 20 13:17:58 yeah thats the same iam reading Aug 20 13:18:27 im trying now to put debugshell as kernel option so it breaks out of the udev script and bring me to shell Aug 20 13:19:09 can i overrite a script in an recipie from an other recipie ? Aug 20 13:19:16 hi, when I am building 32 bit stuff with Yocto on a 64 bit host, do I need to have a lot of 32 bit libraries around or Yocto will build those for me? Aug 20 13:19:25 daBONDi_work: make a bbappend Aug 20 13:19:54 lpapp: should just work Aug 20 13:20:31 tf: will the rootfs.img get copied to a ram root fs? Aug 20 13:21:02 or will system mount the img itself Aug 20 13:22:20 daBONDi_work: if you choose the 'boot' option, it creates a loop device and mounts the rootfs.img on the loop device Aug 20 13:22:47 the rootfs.img is not a ram image Aug 20 13:22:58 what 'boot' option? Aug 20 13:22:59 bluelightning: http://pastebin.com/3WwNnEtw Aug 20 13:23:43 new blog post: http://hambedded.org/blog/2013/08/20/waiting-for-removable-media-problem/ Aug 20 13:24:01 daBONDi_work: when the live image first boots, you get an option in the bootloader to either 'boot' or 'install' Aug 20 13:24:07 the default is 'boot' Aug 20 13:24:18 i make a syslinux bootloader config Aug 20 13:24:24 sure Aug 20 13:24:24 and pass the initrd and kernel file Aug 20 13:24:30 sure Aug 20 13:24:52 daBONDi_work: the init script that is waiting for removable media is part of the initrd Aug 20 13:26:07 because the initrd is just a small image that loads / installs the real image Aug 20 13:26:24 you want to make a real image, with a normal init program instead, I think Aug 20 13:26:25 ahh now i get it Aug 20 13:26:45 yes i want a system hows run completly from ram Aug 20 13:26:47 after start Aug 20 13:27:06 basically, you want the rootfs from something line core-image-minimal Aug 20 13:27:18 but build in the appropriate format for the ram disk Aug 20 13:27:27 yes :-) Aug 20 13:27:48 which is cpio.gz, if I am not mistaken Aug 20 13:27:57 yes thats what i was reading Aug 20 13:28:18 I don't think core-image-minimal builds cpio.gz by default Aug 20 13:28:20 cfo215: run bitbake -e | less and search for hello (with / ) Aug 20 13:28:22 you need to enable that Aug 20 13:29:37 daBONDi_work: plus you will need to make sure the ramdisk is big enough, there are some kernel params for that, iirc Aug 20 13:29:56 thx Aug 20 13:30:01 bluelightning: will grep do? Aug 20 13:30:06 will check, thx tf! for clueing the thing with initrd! Aug 20 13:30:15 cfo215: not really, we want to see how it's being set Aug 20 13:30:45 bluelightning: Will do. Aug 20 13:32:47 daBONDi_work: you might want to create your own image recipe from something like core-image-minimal, and just change the IMAGE_FSTYPES in the recipe (see core-image-minimal-initramfs for that) Aug 20 13:37:40 so i make a copy of core-image-minimal-dev.bb(Inerits core-image Minimal.bb with dev-pkgs) put it in my own layer and add IMAGE_FSTYPE=cpio.gz to it, or something like that, will try tf THX Aug 20 13:37:45 bluelightning: http://pastebin.com/3yTjKHaS Aug 20 13:38:18 cfo215: so basically on line 45 of your local.conf you are appending " hello" Aug 20 13:38:23 cfo215: if you don't want that, remove it :) Aug 20 13:43:02 bluelightnight: sure enough "IMAGE_INSTALL_append += "hello"... but now I'm really confused. Should I use my layer from bblayers.conf or use IMAGE_INSTALL_append += "" in local.conf? Aug 20 13:44:17 cfo215: it's not really either-or Aug 20 13:44:22 cfo215: two different things Aug 20 13:44:39 cfo215: if you want to add a layer to your configuration, the path to it has to be added to conf/bblayers.conf Aug 20 13:45:10 cfo215: the IMAGE_INSTALL_append is adding a package to be installed in your image Aug 20 13:45:47 cfo215: I'm assuming you changed your bblayers.conf to remove the layer that contained the recipe that provided a "hello" package, but since you didn't remove the line from local.conf that added that package to your image -> error Aug 20 13:47:50 bluelightning: Yes, that is correct. So if I understand it correctly then if i have a recipe in my layer but don't included it in bblayers.conf I could still use a recipe from it by 'IMAGE_ISTALL_append'ing the recipe name. Aug 20 13:48:07 cfo215: no, that's not right Aug 20 13:48:30 bluelightning: ic Aug 20 13:49:03 cfo215: if a package is mentioned in IMAGE_INSTALL there must be a recipe providing it or you'll get the error you were getting Aug 20 13:49:18 there's not a lot more to it than that Aug 20 13:50:56 bluelightning: I guess I was thinking that if the recipe was in the sources folder, even though it's parent layer was not included in the bblayers.conf file that bitbake would find it. Aug 20 13:51:47 bluelightning: ... if I used IMAGE_INSTALL to make a reference to it. Aug 20 13:52:51 bluelightning: Thanks for all your help! I've got to get moving on... Aug 20 13:52:58 no, IMAGE_INSTALL doesn't at all influence the recipes that are parsed Aug 20 13:53:03 ok Aug 20 13:53:06 np Aug 20 13:54:04 bluelightning: I'm still trying to get my head around all the configuration docs. It will come... or my head will explode. Either, I suppose, will work. Aug 20 13:55:29 hi, I am again :-) i got a recipie in my layer, in the bb file(its an new Image File), i have follow line: "require core-image-minimal.bb" Aug 20 13:55:30 how can i include something from an other layer in an bb , bitbakes tells me it cannot finr core-image-minimal.bb Aug 20 13:57:29 bluelightning, Hey dude, I have a problem. I hope you have some advice. Aug 20 13:57:49 The boss N' I are trying to update the recipes for our own code, which needs to be fetched from our private git repository Aug 20 13:58:09 We have set it up so that he is authenticated via ssh, so no credentials are need to push or pull. Aug 20 13:59:10 And now, we've added something like git://bitbucket.org/movis/movisboxsite;protocol=ssh;branch=master;user=git Aug 20 13:59:36 This is what we've managed to find that doesn't generate errors outright... Aug 20 13:59:50 bluelightning, Okay, as I"m typing this, he actually managed it. :P So sorry to disturb you. Aug 20 14:00:01 Hey Stygia Aug 20 14:00:10 It's that guy, BTW. Aug 20 14:00:11 Stygia: ok, happy to be your cardboard cutout developer ;) Aug 20 14:02:00 daBONDi_work: use the full path from the base of the layer Aug 20 14:02:17 daBONDi_work: i.e. require recipes-core/images/core-image-minimal.bb Aug 20 14:05:22 bluelightning: THX it works, was obvious, why iam not thinging about this :-), maybe i dont understand the system, do it combine all layers to 1 big thing? Aug 20 14:06:15 daBONDi_work: no, you just clone/extract each one wherever it makes sense, then point to them in the conf/bblayers.conf file under your build directory Aug 20 14:07:59 ok this is why the Path is only recipies-core/.. because meta = layer is in bblayers.conf and got submerged to the big Virtual bblayers.conf Directory/configfile/or wathever :-) Aug 20 14:11:39 now i get it, documentation is quite confusing :-), thx 4 your time Aug 20 14:12:38 bluelightning, Hah it wasn't quite like that, I genuinely didn't know, my boss' just managed to make it work after he asked me to come ask here. Aug 20 14:12:50 bluelightning, FYI you've made a noticable impact in our company's efforts to get profitable. :P Aug 20 14:12:54 bluelightning, We should pay you or something. Aug 20 14:13:12 Stygia: it's ok, I'm happy to help :) Aug 20 14:13:18 bluelightning, Yea I know. :) Aug 20 14:13:40 Stygia: the perl recipe contributions you're preparing will be more than sufficient recompense :) Aug 20 14:15:24 bluelightning, Heh yea I'm hoping so. Aug 20 14:15:48 libX-something-perl, Artistic-1.0+ | GPL-1.0+, all this stuff is gradually getting there... Aug 20 14:19:44 bluelightning, This, titled libtaint-util-perl: http://pastebin.com/v4WnDKSq Aug 20 14:19:49 bluelightning, That's what you'd want commited, yea? Aug 20 14:20:47 Stygia: yep Aug 20 14:20:48 bluelightning, With section set to 'libs', but still. Aug 20 14:21:01 Stygia: FYI it seems like we inherited this naming scheme from debian, fwiw: http://packages.debian.org/search?keywords=libtaint-util-perl Aug 20 14:21:40 bluelightning, Yea, it does match the debian one very closely. Aug 20 14:57:20 YPTM: davest is in the meeting! Aug 20 14:57:32 YPTM: Paul Eggleton joined Aug 20 14:57:36 YTPM: Saul is on and will be leading this week Aug 20 14:58:33 YTPM: Is the Yocto Project Tech Meeing Con-Call Starting now Aug 20 14:58:33 Dial-in number: 1.972.995.7777 Aug 20 14:58:33 Participant passcode: 42001078 Aug 20 14:59:03 This call is open to all and the channel remains open to discuss any topic. Aug 20 14:59:04 YTPM: MatthewW is on Aug 20 15:00:22 YPTM: Tom Z on Aug 20 15:00:53 YPTM: belen joined Aug 20 15:01:09 YPTM: Cristian joined Aug 20 15:02:07 YPTM: Richard is on the call Aug 20 15:02:15 YPTM: Beth is on the call. Aug 20 15:02:17 YPTM: Corneliu joined Aug 20 15:03:14 YPTM: Polk is here Aug 20 15:03:22 YPTM: Mark is here Aug 20 15:03:38 YPTM: jzhang's here Aug 20 15:03:40 YPTM: Bruce will be late. Aug 20 15:04:04 https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status Aug 20 15:04:25 YPTM: nitin on the call Aug 20 15:04:40 YPTM: ross on Aug 20 15:05:26 argh, what's the code? Aug 20 15:05:50 42001078 Aug 20 15:06:15 thanks Aug 20 15:06:24 YPTM: Björn is on the call Aug 20 15:10:57 YPTM: Michael present. Aug 20 15:12:53 pidge: can i grab you for 5 after the call? Aug 20 15:17:52 rburton: sure Aug 20 15:20:02 hi, how can I get a package list what core-image-minimal builds? Aug 20 15:20:37 enable buildhistory Aug 20 15:20:46 without building. Aug 20 15:20:56 I would like to see what it will build. Aug 20 15:21:07 and judge if that is good enough for me. Aug 20 15:22:44 lpapp: bitbake -g will give you the dependency tree, from which you can get the package list Aug 20 15:22:59 its not exactly what you want though, but it will work now Aug 20 15:23:15 rburton: sounds like something to be reported. Aug 20 15:23:28 hi i can boot the generated hddimg file from a cf card on the device, how i can boot it with syslinux and the rootfs is in ram so the system dont need the cfcard anymore, is that even possible ? can someone point me in a direction? thx Aug 20 15:23:32 it would be nice for the users to be able to get the package list for an image, anytime, anywhere. Aug 20 15:26:51 rburton: is there a report about it, already Aug 20 15:30:06 rburton: reported because I have not found anything quickly, https://bugzilla.yoctoproject.org/show_bug.cgi?id=5025 Aug 20 15:30:07 Bug 5025: normal, Undecided, ---, saul.wold, NEW , Query the package list built by an image Aug 20 16:11:24 sgw_: re the PACKAGE_EXCLUDE functionality, you can see my comment here: http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082760.html Aug 20 16:11:33 bluelightning: I am reviewing fray's patch set, and the pending question is if we persist the excluded package list or not, correct? Aug 20 16:11:40 sgw_: yes Aug 20 16:11:59 bluelightning: Yeah, I have read both your message and fray's reply Aug 20 16:12:06 ya.. I don't think it is necessary myself.. but I can see why someone could expect it.. Aug 20 16:12:11 to my mind it makes sense that the excluded packages stay excluded; the user is free to disable the exclusions Aug 20 16:12:28 seebs: when you have a minute can you please check http://pastebin.com/C5Z1jYCg and suggest what else to try with pseudo? Aug 20 16:14:36 bluelightning: I can see both sides of this as fray points out. I would tend to fall to leaving them transient since 2 of 3 package systems don't support persistence (at this time) and in most cases there won't be the data on the system anyway. Aug 20 16:15:10 bluelightning: it would take user action on a system with pkg-management enabled to install something new. Aug 20 16:16:02 the (common) case where the package manager and associated db are not installed don't enter into this discussion, this is about when they are Aug 20 16:16:27 bluelightning: fray: The question that comes to mind is will an update unwittingly cause a previously excluded patch to be included? Aug 20 16:16:40 or just the user action of adding a package? Aug 20 16:16:43 if it were only a matter of the user explicitly installing items on the excluded list then this wouldn't be an issue Aug 20 16:18:56 bluelightning: so the question is: when updating a system, will a previously excluded patch be installed? Possibly due to a change in dependecies? Aug 20 16:19:20 s/patch/package/ Aug 20 16:19:22 I don't see how it couldn't be Aug 20 16:22:50 yes package, Aug 20 16:26:33 bluelightning: I am still leaning to leave it transient, as fray sez it's a limited case, this can be address at a later time if it becomes an issue, even if we wanted it to persist we could only make it work for rpm in the time frame we have. Aug 20 16:27:26 sgw_ sorry back.. ya.. a field upgrade could bring in exclude packages.. Aug 20 16:27:33 but I'm not sure if that is a good or bad thing.. Aug 20 16:28:28 fray: that what this seems to hinge on, you have more background on deployments at this point, so you would have to answer that question. Aug 20 16:28:46 for a desktop environment, it'd be a problem.. Aug 20 16:28:54 for an embedded environment, I'm not sure it is.. Aug 20 16:29:19 the people I know who want the exclusion stuff will likely NOT be doing package based field upgrades.. or at least not ones with packages available theyd on't want installed -- ever Aug 20 16:30:39 so it kind of sounds like it doesn't matter one way or another for most cases Aug 20 16:30:56 As I think about this, I can see an edge case of excluding a package that provides a service and then it being installed and started, it uses resources (disk and cpu) which could have un-intended effects on the embedded systems, I could be talking may way the other direction! Aug 20 16:31:04 in which case, we can merge the patches as-is, but I will be working on a follow-up series that makes it persist Aug 20 16:31:31 so far I haven't heard a convincing argument as to why it should not Aug 20 16:32:55 bluelightning: given I have just started to look at think about this, I think that's a good direction to take. If we have a persistent patch set then we won't run into issues that might occur. Aug 20 16:33:27 fray I will pull in your updated patch set. Aug 20 16:36:11 https://gist.github.com/kergoth/6283884 - any thoughts? Aug 20 16:37:54 kergoth: do we need to add another class for this? Aug 20 16:38:19 sorry, having way way too many discussions at once.. catching back up Aug 20 16:38:36 kergoth: I like the idea of centralising this, it's just that the number of classes we have is only going up :( Aug 20 16:39:44 bluelightning / sgw_ : I can't say I have a compelling argument either way honestly.. the existing implementation is simply there to be consistent across package managers (to avoid suprises).. and this met the 'easiest way to implement the solution' Aug 20 16:40:18 it's certainly easier on smart to store the exclusions then it was on opkg / deb Aug 20 16:41:06 bluelightning: we could put it in cml1.bbclass, but then we'd need a way to opt-in to it, since we don't want to break existing recipes. Aug 20 16:41:15 bluelightning: so.. options are limited afaict Aug 20 16:44:31 * kergoth shrugs Aug 20 16:44:36 kergoth: looking at this, surely there's a way to make it not break anything... Aug 20 16:45:10 i don't see how. Aug 20 16:45:33 but i'd certainly be interested to see it Aug 20 16:46:45 fray: I think we have a plan moving forward, to start with your implementation, and then move to a persistent model, with you and bluelightning looking at the creating the persistent version Aug 20 16:47:14 I guess you could make it not do anything if DEFCONFIG is unset, but still fail if the path doesn't exist, then alter kernel.bbclass to set DEFCONFIG to KERNEL_DEFCONFIG by default, for compat with existing recipes. but then there's the question of default behavior if neither defconfig nor kernel_defconfig are set by the recipe, does it trust the recipe knows what its doing, or does it default to ${WORKDIR}/defconfig the way kernel.bbclass does today Aug 20 16:47:23 sgw_ works for me Aug 20 16:47:32 fray: great Aug 20 16:47:34 the problem is, many kernel recipes prepend to do_configure to create .config and everything Aug 20 16:47:41 there's no way to inject code between that and the actual configuration Aug 20 16:47:43 * sgw_ back after a run Aug 20 16:48:05 so there's no way to automatically do it without the recipe opt-ing in to this manner of configuration Aug 20 16:48:32 * kergoth goes to get food and caffeine and think about it Aug 20 16:48:38 in some ways, this type of change seems reasonable to me as a 'compatibility' break.. Aug 20 16:48:56 lets get rid of the inconsistencies.. and explaint o people how to 'fix' the recipes that use the cml1 class Aug 20 16:49:11 my only question though is right now appropriate for implementation, or does this need to wait for 1.6? Aug 20 16:49:15 only if it could be made to error out when using "incompatible" recipes Aug 20 16:49:23 bluelightning yes.. Aug 20 16:49:34 detectign that is a question... Aug 20 16:50:38 i thought about making it chmod -w .config in prepare_config, so do_configure would error out if it tried to write to it, but that'd break use of minimal defconfigs w/ oldconfig filling in the gaps Aug 20 16:51:38 JaMa: That does indeed look like files are getting created by statically-linked binaries. We've got basically nothing for that right now, except "rebuild binaries dynamically linked". Aug 20 16:52:03 Would be interesting to run more comprehensive logging in some other way to see when those files are created, and what by. Aug 20 16:53:52 aside: we should also dro pour "yes '' | oe_runmake oldconfig" bits in kernel.bbclass in favor of oe_runmake silentoldconfig (though it'd change the behavior from auto-enabling what's missing to using its default values, but that's much more sane anyway..) Aug 20 16:57:32 er, no, nevermind that, i forgot about yes's argument behavior :) Aug 20 17:20:49 seebs: ah I forgot to mention that this one was created with internal toolchain Aug 20 17:22:11 seebs: the same happens e.g. with procfs utils, I'm running another build from scratch to see if the list of modified file atributtes is the same Aug 20 17:22:15 Hmm. Interesting! Then we may actually have a case of something bypassing pseudo and moving files around. I suppose in theory you could try to run things with pseudo's logging on, it can be very verbose. Aug 20 17:24:09 It's at least a little disturbing for a file to be showing up in the database with 'no path', that sort of implies that it got added in some unexpected way. Aug 20 17:24:15 PSEUDO_DEBUG=5 should be enough? Aug 20 17:24:31 Don't use PSEUDO_DEBUG, that's... useless, really. Aug 20 17:24:52 I don't know off the top of my head how to export the right values, I think it might just be PSEUDO_OPTIONS=-l Aug 20 17:25:06 Pseudo has a logging mode where it creates a log database which records every operation. Aug 20 17:25:15 This is much more informative than the debug crud. Aug 20 17:25:23 ok Aug 20 17:25:40 BTW, I have patches that improve the debug stuff a LOT. Aug 20 17:25:44 I'll try to create some smaller reproducer then image which takes 3 hours to build from scratch :) Aug 20 17:25:48 My background task is fixing it. Aug 20 17:26:07 Basically, in my tree, PSEUDO_DEBUG=[letters] toggles various debugging flags. Aug 20 17:26:25 So you don't have to have verbose reporting on every aspect of everything to get information about IPC. Aug 20 17:31:40 sounds nice Aug 20 17:32:03 In retrospect, I have no idea why I didn't do it that way in the first place. Aug 20 18:23:03 khem: around? Aug 20 19:04:58 howdy challinan Aug 20 19:05:32 hey mranostay how are ya? Aug 20 19:08:55 oh it is going Aug 20 19:13:35 mranostay: you going to ELC-E? Aug 20 19:17:43 <_alex_kag_> hello, does qt4e-demo-image broken? it buiding good, but then i run it - qtdemoE -qws is segmentation fault Aug 20 19:19:25 <_alex_kag_> i try run it on imx6qsabresd Aug 20 19:26:06 _alex_kag_: try '$ file qtdemoE' to see if it compiled properly for your target. It should give you something like " ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped" if it compile correctly for your target. my target is ELF 32-bit LSB on ARM processor. Also, make sure all your required libraries are on the target (if using shared libraries). Aug 20 19:28:19 seebs: sorry to interrupt you again, but where should I find logs from PSEUDO_OPTIONS=-l? pseudo.log and logs.db looks the same as before Aug 20 19:29:09 The logs.db should be huge. If they're not, it's quite possible that, say, bitbake is helping by stripping PSEUDO_... oh. Aug 20 19:29:12 PSEUDO_OPTS Aug 20 19:29:34 I should perhaps point out that my memory for words is occasionally quite bad, and it never hurts to check what I say against the man page. :) Aug 20 19:31:33 I've used sysroots/x86_64-linux/usr/bin/pseudo --help | grep -i PSEUDO without any output :) Aug 20 19:31:59 btw not sure if it's intentional but -l is described as long and later as verbose format Aug 20 19:34:26 <_alex_kag_> cfo215: thanks, tomorrow will test Aug 20 19:36:08 It's not --help. There is an actual man page. Aug 20 19:36:10 how do you extend IMAGE_FEATURES += "dev-pkgs" to include a custom development package from a custom layer? I tried finding dev-pkgs* but it must not be a .bb file or *.inc file. Aug 20 19:36:15 See pseudo.1 in the pseudo directory. Aug 20 19:38:05 seebs: yes I'm reading it now Aug 20 19:38:28 seebs: --help is a bit more accessible when using pseudo from OE Aug 20 19:39:00 Yes. Although currently pseudo doesn't actually have *any* long options, so all it's doing is displaying the default usage stuff because - isn't a valid option. Aug 20 19:39:31 The man page is probably too large to be encapsulated in --help output, but I could probably improve it some. Aug 20 19:40:20 strassek_: btw there is also many entries in pseudo.log about path mismatch Aug 20 19:40:23 pseudo: path mismatch [2 links]: ino 49477724 db '/OE/work/i586-oe-linux/perl/5.14.3-r1/pkgdata/runtime/perl' req '/OE/pkgdata/i586-oe/runtime/perl'. Aug 20 19:40:35 Where is -l described as "long" and later as "verbose" format? I am not sure what you were looking at. Aug 20 19:40:36 I belive it's caused by using hardlinks Aug 20 19:41:00 Yes. pseudo is okay with those, they're advisory warnings -- thus the "path mismatch [2 links]". Aug 20 19:41:12 It is suspicious but those aren't regarded as fatal errors, in general. Aug 20 19:41:21 from --help: Aug 20 19:41:22 --format=WORD across -x, commas -m, horizontal -x, long -l, Aug 20 19:41:22 single-column -1, verbose -l, vertical -C Aug 20 19:42:47 ... Which program's --help is that? It does not look familiar to me. Aug 20 19:43:19 pseudo --help Aug 20 19:43:35 well pseudo version used in dylan release Aug 20 19:44:09 Those options aren't at all related to pseudo, but I have no idea what they ARE from. Aug 20 19:44:11 omg please ignore it :) Aug 20 19:44:32 Looks like diagnostics from ls. Aug 20 19:44:34 I forgot leading "ls" before path to pseudo Aug 20 19:44:52 * JaMa needs more coffee or less rum or something Aug 20 19:45:12 ... And of course, rather than "ls path --help" telling you that there's no file --help, it "helpfully" interprets the option anyway. Aug 20 19:45:15 I hate that behavior. Aug 20 19:47:51 btw the list of files with different file attributes is changing a bit with each rebuild from scratch, I'll let you know if I find something interesting in logs.db after few hours Aug 20 19:51:18 It really feels like something is moving files around that pseudo was tracking, and doing so outside of pseudo. Aug 20 19:51:38 Either statically-linked binaries, or a syscall I don't know about yet, or just some harmless bookkeeping task that needed a fakeroot qualifier and didn't get it. Aug 20 20:24:26 So, I think I have meta-sourcery working with multilibs, too, now. Aug 20 20:24:50 nice Aug 20 20:25:07 It turned out to be stunningly easy, except for the 45 minutes I spent unable to figure out why nothing at all was working. Aug 20 20:25:16 i hate those days Aug 20 20:25:34 Answer: I had some buggy code, I wanted to run bitbake -e to examine some values, and I had put a "return" above a large hunk of necessary functionality so that bitbake -e would work, then forgot to remove it. Aug 20 20:25:50 Only got it when I did a "git diff" to look at all the changes in case I'd done something obviously wrong. I had. Aug 20 20:26:19 ugh, yes, ConfigParsed time sanity checking sucks Aug 20 20:26:29 I am not sure at all whether my multilib handling is right. Aug 20 20:27:10 It's basically a check for MULTILIB_VARIANTS, and if that's set, for each one, get a new d.createCopy(), get DEFAULTTUNE_virtclass-multilib-%s, set DEFAULTTUNE to that, finalize, and invoke populate_toolchain_links on that. Aug 20 20:27:23 I feel that this is almost certainly overengineered, but I am not sure of a simpler way. Aug 20 20:28:51 ... My build failed due to a kernel source file producing a warning, which was treated as an error. Aug 20 20:29:18 Original plan: Use our XLP-based BSP to quickly confirm that I'm generating the right name for the multilib subdirectory, which I need to make a one-line change. Aug 20 20:29:29 Actual outcome: Roughly 9 hours of debugging how meta-sourcery interacts with multilibs. Aug 20 20:31:56 ... But I did successfully make the one-line change, so that's a win. Aug 20 21:21:30 Hi LiangC Aug 20 21:21:52 Hi Beth? Aug 20 21:22:02 yes! Aug 20 21:22:50 Looking forward to working with you:) Aug 20 21:23:29 ditto. we'll take this to pm. Aug 20 21:24:05 sure Aug 20 21:31:29 * mranostay yawns Aug 20 21:34:34 khem: around? Aug 20 21:35:25 RP: Should I resubmit my proposed patch to improve the reporting when shell commands cause an exit due to set -e? Aug 20 21:39:59 seebs: I'll merge it, it just about still applies Aug 20 21:40:07 Okay, thanks! Aug 20 21:41:00 woo Aug 20 21:41:02 that'll be handy Aug 20 21:41:10 just yesterady i got bit by a quietly failing task :) Aug 20 21:41:36 if it saves time, we have a version that applies to bitbake as of about a week ago Aug 20 21:43:11 The worst of those we ever had involved a tar command which wasn't actually failing silently. Aug 20 21:43:24 It was emitting an error message followed by several thousand lines of non-diagnostic normal output. Aug 20 21:43:54 So we didn't *see* the error message, we just saw a sudden exit for no reason. A patch similar to this at least told us tar was exiting with a non-zero status. Aug 20 21:44:19 its in Aug 20 21:44:20 huh, this kernel build is putting the generated dtbs in arch/arm/boot/dts/, not in arch/arm/boot/ the way linux-dtb.inc is expecting Aug 20 21:44:29 causing a do_install failure. wonder if thats specific to this bsp kernel or what, weird Aug 20 21:44:45 kergoth: I think a patch just landed for that Aug 20 21:46:19 ah, indeed, didn't see that Aug 20 21:46:19 cool Aug 20 21:47:18 Does anyone see any value in the current gcc .inc files or are we better collecting things into less files? Aug 20 21:47:54 I'm finding it a twisty maze and I doubt anyone else finds it easier :/ Aug 20 21:48:03 I'd have to double-check, but I *think* we may be using some of that in our build stuff. Or may not be. Aug 20 21:48:58 ... Woah, there are a LOT more of those than I realized. Aug 20 21:49:06 I would guess that we could get away with fewer. Aug 20 21:49:50 i'm not big fan of .inc use in recipes anymore for that reason, it definitely gets confusing Aug 20 21:50:21 though i'd like to resurrect my vim bits that made 'gf' work on required/included/inherited files in recipes Aug 20 21:50:27 There are some simple no brain fixes like killing gcc-cross4.inc which I have a patch for Aug 20 21:50:35 cause that was awesome when it worked (back when BBPATH was in the env) Aug 20 21:50:55 but do we merge the gcc-configure-* and gcc-package-* ? Aug 20 21:51:02 RP: did you grab the other half of otavio's DISTRO_FEATURES for poky.conf? Aug 20 21:51:09 gcc-configure-common and gcc-common ? Aug 20 21:51:14 sgw_: no, not yet Aug 20 21:52:17 RP: for what its worth, there might be value in keeping packaging separate for things like external toolchains, if at any point we want to be able to split out independent recipes for things Aug 20 21:52:36 course thats more important for eglibc than gcc :) Aug 20 21:53:13 kergoth: right, eglibc is a very different situation. If you look at the gcc-package bits, its mostly the do_install functions :/ Aug 20 21:53:26 ahh, right, in that case, likely just adds confusion Aug 20 21:54:44 kergoth: that is my current feeling, the split is currently rather confused... Aug 20 21:55:02 sgw_: The reason I haven't done anything with the patch is I can never find the thing Aug 20 21:55:16 sgw_: If people sent them to the right mailing lists, I might do a better job of that Aug 20 21:57:52 RP: it went to both poky and oe-core might have been sucked into one filter or the other Aug 20 22:00:52 sgw_: the resend went to OE-Core only afaict Aug 20 22:01:22 I'd marked the original as obsolete which makes it effectively disappear Aug 20 22:05:47 does any one had any problem with python linkage while building perf? Aug 20 22:09:21 ftonello: failure at do_rootfs? Aug 20 22:10:06 bluelightning: no, while linking Aug 20 22:10:19 ok, then no, maybe someone else has Aug 20 22:10:33 stuff like /usr/src/kernel/tools/perf/scripts/python/Perf-Trace-Util/Context.c:87: undefined reference to `Py_InitModule4' Aug 20 22:12:22 I will just disable it, but it's weird because I have python installed.. probably a bug in the recipe Aug 20 22:40:53 so, i've seen host compiler ICE's building qemu 1.5.0 in the past, but we found bumping to 1.5.1 sidestepped the issue Aug 20 22:40:59 thoughts on updating qemu in the core? Aug 20 22:49:51 anyone out there know what the default password is for the Angstrom 2012 core-image-minimal build. I've tried all the obvious ones. I thought it was supposed to be blank. Aug 20 22:50:21 try the angstrom channel Aug 20 22:51:54 How/where do you set the default password for the yocto core-image-minimal build? Aug 20 22:55:15 cfo215, you probably want to enable # "debug-tweaks" as EXTRA_IMAGE_FEATURES Aug 20 22:55:26 check out local.conf examples Aug 20 22:55:43 ant_home: thanks I'll look at that. Thank you. **** ENDING LOGGING AT Wed Aug 21 02:59:58 2013