**** 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