**** BEGIN LOGGING AT Mon Jan 28 03:00:00 2013 Jan 28 08:53:33 good morning Jan 28 09:05:15 morning all Jan 28 09:32:34 Hi , how can I search in the Yocto mailing list? for example I want to know if someone asked before how to "boot target image from USB flash disk with NFS rootfs" Jan 28 09:33:47 I tried to enter "nfs boot" in the mailing-lists page's search textbox , but like it not search the archive. Jan 28 09:45:30 EddyLaiTW: usually entering this string in google may help: lists.yoctoproject.org nfs boot ;-) Jan 28 09:52:20 or even site:lists.yoctoproject.org nfs boot Jan 28 09:52:23 morning all Jan 28 12:42:14 night Jan 28 12:43:55 Is it the same for COMPATIBLE_MACHINE = "(abc)" vs COMPATIBLE_MACHINE = "(abc.*)" Jan 28 14:12:25 RP : Is it the same for COMPATIBLE_MACHINE = "(abc)" vs COMPATIBLE_MACHINE = "(abc.*)" Jan 28 14:12:59 lyang0: I think so, not 100% offhand Jan 28 14:13:34 I tied it today, it seems the same Jan 28 14:16:54 If I have two machine, one is abcx, the other is abc. I only want it compatible with abc, it seems we can't distinguish it with COMPATIBLE_MACHINE = "(abc)" Jan 28 14:21:18 lyang0: it's a regex... so you'd probably need to do "^abc$" or something similar Jan 28 14:21:52 good answer Jan 28 14:23:05 OMPATIBLE_MACHINE = "(abc)" == COMPATIBLE_MACHINE = "(abc.*)", that's strange, I thought COMPATIBLE_MACHINE = "(abc)" only match abc before. Jan 28 14:23:34 for now, it's like grep abc vs grep "abc.*" Jan 28 15:04:41 JaMa: ping me if the reply about hash functions doesn't make sense Jan 28 15:10:38 RP: sounds very interesting and usefull Jan 28 15:11:01 RP: only OEBasic/OEBasicHash names will be a bit misleading Jan 28 15:11:14 JaMa: yes, I know Jan 28 15:11:31 JaMa: if it works we can worry about what to so about that Jan 28 15:12:03 JaMa: Probably rename OEBasic -> OEBasicHashLite Jan 28 15:12:05 or something Jan 28 15:12:32 true, but for my use-case it looks like big improvement Jan 28 15:12:47 especially now without PR bumps Jan 28 15:16:11 JaMa: It gives you some of the benefits whilst avoding your main pain point of the rebuilds Jan 28 15:16:19 yes Jan 28 15:16:26 what about changes in global config Jan 28 15:16:32 that will cause rebuilds, right? Jan 28 15:16:42 JaMa: yes, that is true Jan 28 15:17:06 maybe we could keep OEBasic and add new one directly as OEBasicHashLite? Jan 28 15:17:27 I'll try to use it for some time Jan 28 15:17:35 JaMa: possibly, my worry is that OEBasic will likely break further :/ Jan 28 15:18:09 JaMa: Some other notes: The two hash namespaces would become incompatible so an OEBasicHashLite build wouldn't use OEBasicHash sstate objects and vice versa Jan 28 15:18:27 can we extend that filter a bit more? e.g. that formal change in license.bbclass rebuilds all packages Jan 28 15:18:32 JaMa: You might also be able to avoid the worst of global changes if you exclude some key variables Jan 28 15:18:45 which is OK and good thing for official build Jan 28 15:18:48 JaMa: do_package and do_configure being the ones that probably trigger most of the remaining changes Jan 28 15:19:25 JaMa: you can change the filtering, yes. Its all configurable Jan 28 15:20:47 but you don't know the source of that change, right? E.g. if someone changes PACKAGES variable in recipe I want to rebuild, but if someone adds extra space in default PACKAGES in bitbake.conf I would like to ignore it Jan 28 15:25:57 JaMa: correct, telling the difference is extremely hard Jan 28 15:30:38 * JaMa going to test http://bpaste.net/show/73428/ Jan 28 15:32:24 JaMa: looks reasonable Jan 28 15:33:16 forget one s/_basic/_lite/, updated locally Jan 28 16:07:18 I need some assistance with an issue I'm having with yocto udev: I have a device shared by two embedded controllers and only one controller at a time can load the device driver. Unfortunately, udev is auto-loading the driver for this device and I have not been able to blacklist this device no matter what i have tried. I tried adding /etc/modprobe.d/blacklist.conf and adding "blacklist seepmtd" along with some other things along these lines, but Jan 28 16:07:18 the driver is always auto loaded. Jan 28 16:44:28 http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/035024.html Jan 28 16:44:50 anybody have ideas around udev blacklist not working for newer kmod-based udev? Jan 28 16:47:47 zeddii, do you know of any reent BSP's that point to device tree files? Jan 28 17:13:43 what is the easiest way to disable a layer? Jan 28 17:14:11 remove it from the layers file? Jan 28 17:14:39 Crofton|work: then re-source setup-environment? Jan 28 17:14:49 Crofton|work. only the meta-fsl-ppc BSPs that I know off hand, at least for BSPs off git.yoctoproject.org. Jan 28 17:14:51 I do not think you need to do that Jan 28 17:14:59 ah ppc Jan 28 17:15:04 I forgot to look in tehre Jan 28 17:15:19 before I whine about this, I want to look at something that should work :) Jan 28 17:15:48 I looked in fsl-arm :) Jan 28 17:16:54 hmm Jan 28 17:16:58 fsl-ppc not helpful Jan 28 17:17:53 Crofton|work, you are looking for multi-dtb / DEVICE_TREE examples ? Jan 28 17:18:55 yeah, but I think the issue is I need to use KERNEL_DEVICETREE_EXTRA for ones I pass in from SRC_URI? Jan 28 17:20:01 these are the device trees that are conditional on the machine ? or is the trigger something else ? Jan 28 17:20:12 yes Jan 28 17:20:23 there wil be a few dt's for each machine Jan 28 17:21:03 for various configs of the machine. I know I've seen examples of 32/64 bit, ethernet switching, etc for device trees. I'll rummage in my email. Jan 28 17:21:43 dev boards, people like to boot from various sources Jan 28 17:22:11 yah. switch consoles, etc. in particular with the configurable ones. bootline changes, etc. Jan 28 17:53:01 zeddii, yes I am looking for multi-dtb device tree examples :) Jan 28 19:27:58 bluelightning: there is still small issue with password-less root in dropbear, as soon as it gets upgraded by package-manager it can loose password-less option Jan 28 19:28:18 bluelightning: it would be better to install even empty /etc/default/dropbear and put it in CONFFILES_${PN} Jan 28 19:28:46 bluelightning: openssh is doing that already Jan 28 19:29:51 JaMa: why does it get deleted? Jan 28 19:29:51 bluelightning: well that sed in openssh is a bit too strict but doesn't hurt Jan 28 19:30:07 -PermitRootLogin yes Jan 28 19:30:07 +#PermitRootLogin yes Jan 28 19:30:12 -PermitRootLogin yes Jan 28 19:30:12 +# the setting of "PermitRootLogin without-password". Jan 28 19:30:27 bluelightning: no it can be replaced with default one, if it's provided by distro Jan 28 19:30:46 bluelightning: I know that distro can set CONFFILES in bbappend.. Jan 28 19:31:41 http://paste.debian.net/229758/ Jan 28 19:37:59 I see Jan 28 19:43:08 I'll look into it tomorrow, thanks for the heads up Jan 28 20:04:47 RP: I see that in autoconf-native we depend on perl especially for auto4mte Jan 28 20:05:28 RP: but we rely on host provided perl for that and Config.pm that gets installed as part of autoconf-native reflects the perl version of host Jan 28 20:06:03 that all works fine unless you ask inherit perlnative in a recipe which also calls auto4mte Jan 28 20:06:38 since the versions of perl-native and perl on build host may not match it complains on such systems Jan 28 20:07:13 I have added code to inherit perlnative in autoconf Jan 28 20:07:34 what is your opinion ? Jan 28 21:01:48 zeddii, any idea why my kernel has -- in the version uImage--3.6+gitAU ....... Jan 28 21:02:03 based of linux-yocto-custom Jan 28 21:11:58 hmmm. that is strange. I wonder what is evaluating to "". I'm actually doing linux-yocto-custom builds all day today and haven't seen that. Jan 28 21:12:05 * zeddii looks out the window at the snow. Jan 28 21:13:00 we are going from -6c and snow, to +14c in a span of 36 hours. it's going to be messy. Jan 28 21:15:25 khem: We cannot inherit perlnative in autoconf Jan 28 21:15:56 zeddii: media here refers to those as floods Jan 28 21:16:47 heh. Jan 28 21:26:39 RP: hmm I wonder how can we avoid the perl version it wants in auto4mte Jan 28 21:26:47 this will break shared state too Jan 28 21:27:08 since you may not be able to share it across systems with different perl version Jan 28 21:37:58 fray: around ? Jan 28 21:38:24 fray: I want to tweak smartpm to customized feed server Jan 28 21:38:32 similar to what I had for zypper Jan 28 21:38:38 any knowhow on that ? Jan 28 21:39:23 I was adding a custom .repo file to /etc/zypp/repos.d Jan 28 21:39:30 on image Jan 28 21:40:11 khem: you need to call smart to add a channel Jan 28 21:40:49 khem: see what rootfs_rpm does towards the end Jan 28 21:40:58 khem: the trick would be ensuring it gets done at the right time Jan 28 21:41:00 hmmm ok Jan 28 21:41:12 yeah I have image tweaks class Jan 28 21:41:17 so I can add a task there Jan 28 21:41:28 I guess that would work Jan 28 21:41:37 would be good to have something standard we can have in the core Jan 28 21:41:47 I would agree Jan 28 21:41:55 some variable to override or recipe to extend Jan 28 21:43:14 Crofton|work, didn't find any good dtb examples, but I'll look at it more tomorrow, have to flee to avoid traffice and snow. Jan 28 22:26:16 A scary observation. The OVERRIDES variable contains a lot of inline python these days which triggers the compiler a lot. In perl packaging this results in 10000 data expansions. Pre-expanding OVERRIDES drops the counts to 180 Jan 28 22:26:43 costs only a handful of seconds but is nonethe less an indication that inline python isn't that healthy :/ Jan 28 22:27:40 * andyross thinks he'd choose to blame late-expansion-by-default instead of inline python. This bites bit makefiles too. Jan 28 22:27:44 er, big Jan 28 22:29:24 andyross: well, its an artefact of the way the system works Jan 28 22:29:34 andyross: we never used to have as much inline python though Jan 28 22:32:07 andyross: more to the point, we can change one more easily than the other Jan 28 22:32:35 Fair enough. :) Jan 28 22:33:18 zeddii, I think I have worked through my basic stupidity Jan 28 22:34:47 400,000 calls to "startswith" of which 333,000 were from from os.path.join Jan 28 22:43:44 add an extra if statement, wipe 60,000 of them out :) **** ENDING LOGGING AT Tue Jan 29 02:59:58 2013