**** BEGIN LOGGING AT Mon Aug 01 02:59:57 2011 Aug 01 09:04:10 morning all Aug 01 09:15:01 morning all Aug 01 11:39:44 5 best reasons to use Yocto? Aug 01 12:17:40 RP__: ping Aug 01 12:20:47 dongxiao: pong Aug 01 12:21:49 RP__: one question about ipk and rpm multilib. If extend lib32- prefix, then for ipk, the package name is lib32-xxx, while the rpm package name is still xxx? Is it on purpose? Aug 01 12:22:01 dongxiao: yes, its on purpose Aug 01 12:22:24 dongxiao: The rpm package format can handle multilibs natively within the package format, ipk cannot Aug 01 12:22:59 RP__: This caused a problem whether we need to extend name for "PACKAGE_INSTALL"... Aug 01 12:23:58 dongxiao: We do need it there and the rpm backend would be responsible for filtering/adapting it Aug 01 12:25:16 RP__: OK. so there might be bug in RPM backend, and I will look into it. Aug 01 12:25:43 dongxiao: rpm will work by giving different feeds different priorities Aug 01 12:26:47 dongxiao: The user could potentially describe a situation the rpm backend might not be able to reach directly without some clever manipulation of that variable though which is a concern :/ Aug 01 12:26:59 dongxiao: We might need to pull fray into this discussion Aug 01 12:28:58 RP__: BTW, how to differentiate the normal x86-64 rpm and lib32 version of that rpm? Both of their name is sth like ${PN}-${PV}-${PR}-qemux86-64.rpm Aug 01 12:31:42 dongxiao: You have to tell rpm which one to prefer Aug 01 12:35:17 RP__: Take connman as an example, both the x86-64 version of rpm package and lib32 version package are put in tmp/deploy/rpm/x86_64/, and the package name are both "connman-0.75-r1.x86_64.rpm", thus the latter built one will override the first built package? Aug 01 12:44:16 dongxiao: It depends on the order in which the sat-solver databases are considered Aug 01 12:44:39 dongxiao: I think we might need to split PACKAGE_INSTALL into a list per multilib Aug 01 12:44:57 dongxiao: and then run the install with the sat-solver databases being considered in a given order Aug 01 12:45:18 or otherwise indicate to rpm which version to install Aug 01 12:45:46 The has to be some mechanism to tell rpm this information Aug 01 14:27:20 morning Aug 01 15:20:09 morning Aug 01 15:28:20 RP__: ping Aug 01 15:35:37 sgw: pong Aug 01 15:39:34 RP__: Good afternoon, wanted to sync up with you regarding the state of M3 Aug 01 15:40:16 sgw: ok. I've gone through the pull request. I think there is some further work on patches going to be needed Aug 01 15:40:50 I saw that, there were also some hob related patches sitting waiting in bitbake ml Aug 01 15:41:05 sgw: Right, I'll get to those Aug 01 15:41:32 RP__: Some of those patches were required for getting M3 to build, I guess we will wait for patch respins and an rc2 Aug 01 15:43:04 sgw: I understand but it doesn't make them correct :/ Aug 01 15:43:26 sgw: I think this cycle we're just going to take a little longer than normal to stabilise Aug 01 15:44:29 RP__: I understand. I will be working in parallel to pull together other patches (or have you been working on that also)? Aug 01 15:44:46 sgw: no, I've just been trying to clear emails and figure out where things are at Aug 01 15:45:32 RP__: ok, is oe-core and master buildable again with the patch set you pulled? Aug 01 15:45:48 sgw: possibly not, not sure Aug 01 15:46:41 Ok, I will get fuzzies going again, and we can see what's happening. Aug 01 15:47:23 [17:43] ensc|w Package fbset version 2.1-r4 has no valid architecture, ignoring. Aug 01 15:47:24 [17:43] ensc|w Architecture: armv7a-vfp-neon Aug 01 15:47:36 suppose he did pull today Aug 01 15:53:24 I see a timestamp of just after you said that for koen's fix going in :) Aug 01 15:59:25 RP__: unfortunately things were moving while we were committing meta-zaurus. Do you think that's a right fix? http://paste.debian.net/124769/ Aug 01 19:23:16 so, looks like the tune bits broke qemuppc Aug 01 19:23:25 * kergoth rolls eyes **** ENDING LOGGING AT Tue Aug 02 02:59:57 2011