**** BEGIN LOGGING AT Fri Sep 16 02:59:56 2011 Sep 16 07:25:49 RP__: ping Sep 16 07:25:56 dongxiao: pong Sep 16 07:28:42 RP__: I am stuck in the multilib rpm dependency issue, do you have comments or updates on that? we have task-core-x11-base-1.0-r34.qemux86_64.rpm, and want to ensure it selects connman-gnome-0.5-r7.x86_64.rpm but not connman-gnome-0.5-r7.x86.rpm. Sep 16 07:29:41 dongxiao: I think we're going to have to add the multilib prefix to the machine name in the multilib case Sep 16 07:32:00 RP__: could you give an example? how is the rpm package like after adding multilib prefix? Sep 16 07:33:57 dongxiao: well, it could keep the same name but be placed in a lib32-qemux86_64 directory Sep 16 07:41:25 RP__: sorry I am not describing my problem clearly. we have task-core-x11-base-1.0-r34.qemux86_64.rpm, and it has dependency on connman-gnome. However in our repo, there are two connman-gnome rpm packages, separately named as connman-gnome-0.5-r7.x86_64.rpm and connman-gnome-0.5-r7.x86.rpm. Our purpose is to have the x86-64 connman-gnome installed. However current RPM could not make the right selection since it has no idea whether to choose x86- Sep 16 07:42:55 dongxiao: Isn't this a priority issue and we need to ensure that qemux86_64 specifically selects from x84_64 packages? Sep 16 07:46:03 RP__: sorry I don't know RPM could differentiate the priority of dependencies, could you give some sample? Actually in our current rpm spec file, for example the task-core-x11-sato, it only writes: "Requires: connman-gnome" with no architecture information. Sep 16 07:48:10 dongxiao: Let me ask a different question. Is there is "lib32" flavour task-core-x11-base package, what is that called? Sep 16 07:51:25 RP__: it could be task-core-x11-base-1.0-r34.lib32_qemux86_64 or task-core-x11-base-1.0-r34.qemux86.rpm based on our implementation. I ever sent two version of RFCs, the first version is set to the previous one, and second RFC set the name as the latter one. Sep 16 07:52:51 dongxiao: Is the second case it is in a specially named directory? Sep 16 07:53:12 RP__: yes, it locates in tmp/deploy/rpm/qemux86 folder Sep 16 07:53:40 dongxiao: Thinking about it the second case cannot be used as the internal paths are different from a normal "qemux86" package Sep 16 07:53:53 dongxiao: so it has to be the first case Sep 16 07:54:52 So I think it now comes down to the order we process the sat-solver databases in? Sep 16 07:56:00 Somehow we need to give rpm the context that qemux86_64 packages are "x86_64" and lib32-qemux86_64 are "x86" Sep 16 07:56:30 RP__: is there differences betwwen lib32 rpm package and normal 32bit rpm package? Sep 16 07:57:02 dongxiao: libs could be in "/libxxx" instead of "/lib" Sep 16 07:57:17 RP__: Oh, that's correct! Sep 16 07:58:04 morning all Sep 16 07:58:30 hi bluelightning Sep 16 07:59:19 RP__: for giving rpm the context that qemux86_64 packages are "x86_64" and lib32-qemux86_64 are "x86", my previous approach is to modify the spec file and add architecture information, but it doesn't got acked. Sep 16 07:59:58 dongxiao: was it rejected? I think people are just busy and distracted at the moment :/ Sep 16 08:01:25 RP__: yes it is rejected by mark. But I could not understand how qemux86_64 could select specifically x86-64 but not x86 by other approach... Sep 16 08:02:10 dongxiao: We need more input from Mark then as I also don't understand how to address this Sep 16 08:05:48 dongxiao: Did you update the code in libzypp? Sep 16 08:06:25 dongxiao: Reading mark's reply, I think it sounds like we need to go with case one above but update the compatibility code that is generated as part of libzypp Sep 16 08:10:36 RP__: the libzypp mentioned by Mark is the patch 2/3, but as we just discussed, we cannot use MACHINE_virtclass-multilib-lib32="qemux86", so probably we need to adopt patch2/3 from my first RFC, to use lib32-qemux86-64. But still it may need libzypp change. Sep 16 08:10:57 RP__: my patch to address the dependency issue is patch 1/3, however mark rejected that Sep 16 08:13:05 RP__: the patch 1/3 is to add architecture information in spec file, like Requires: connman-gnome.x86-64 and Provides: connman-gnome.x86-64 Sep 16 08:15:29 dongxiao: I can only really say two things - the tasks packages might not be getting ABI information attached to them but should be so I do think you might be right about needing some patches there. Secondly we could also ensure that libzypp is seeing these packages in the correct way Sep 16 08:16:07 i.e. libzypp should be associating qemux86-64 as a package name with the x86_64 architecture Sep 16 08:20:59 RP__: yes I agree with you. But I am not sure whether Mark has other idea on solving the dependency issue. Sep 16 08:22:48 dongxiao: we'll need to talk to him Sep 16 08:24:27 RP__: hi, I reopened #775 even if it's not exactly the same issue Sep 16 08:24:56 if it's worth, I'll be adding a new bug Sep 16 08:26:06 RP__: I used to communicate with him via Email, however it seems that the efficiency is low. I don't know whether he is working on this issue. Sep 16 08:54:03 * bluelightning -> office Sep 16 09:11:01 dongxiao: I'll try and move this forward... Sep 16 09:12:12 RP__: appreciate a lot. We need to push fixes before rc3. Sep 16 09:32:38 dongxiao: I've sent email Sep 16 15:53:46 RP__: ping Sep 16 16:01:16 sgw: pong Sep 16 16:02:11 Hi RP__, yesterday, I mentioned a problem with non-gplv3 to you in passing, I dug into it a little further and it's related to DISTRO_FEATURES, specifically x11 Sep 16 16:02:30 sgw: hmm, go on... Sep 16 16:02:37 and avahi which add x11. Sep 16 16:03:49 So, I tried to use oe_filter_out in the core-image-basic recipe (which is supposed to be the largest non-gplv3 image) and it did not seem to take. Sep 16 16:04:29 I think there is an ordering issue as to when the DISTRO_FEATURES are changed vs when the parsing and DEPENDS are done. Sep 16 16:05:19 sgw: So what are we trying to solve exactly? Sep 16 16:06:21 ok, I finally have a CLEAR reproducer to the multilib library dependency failure! Sep 16 16:06:22 WOOT! Sep 16 16:07:20 fray: great :) Sep 16 16:07:40 I still can't believe my dumbass typo that stopped me from reproducing this for almost 2 days.. Sep 16 16:07:45 I feel like an idiot for not realizing it Sep 16 16:07:55 RP__: getting x11 out of DISTRO_FEATURES such that when the avahi recipe is parsed it does not find it set and does not include libglade in avahi's DEPENDS Sep 16 16:08:01 (I kept investigating deeper and deeper why I wasn't getting ANY multilib packages installed) Sep 16 16:08:06 fray great news Sep 16 16:08:17 we really need a sanity check for that condition.. (stupidity) Sep 16 16:14:56 fray: agreed - can you file a bug whilst we think about it Sep 16 16:15:05 will do right now Sep 16 16:15:42 sgw: so you want x11 excluded from DISTRO_FEATURES under what condition? Sep 16 16:15:47 sgw: non-gplv3? Sep 16 16:17:15 1488 Sep 16 16:17:31 That's the hard part, it not neccesarily non-gplv3, when we build a certain image, core-image-basic in this case this image should not include x11 components, but it not a distro flag as much as an image issue. Sep 16 16:18:28 sgw: These are DISTRO_FEATURES for a reason - you either turn them on or off but you must always be consistent. You can't do it on a per image basis Sep 16 16:18:29 IMHO x11, like other graphics system should itself be a distro (feature) flag.. do you want graphics? Sep 16 16:19:05 good point, maybe distro flag is the wrong level Sep 16 16:19:07 So then the non-gplv3 has to become a "distro" Sep 16 16:19:12 sgw: inclusion of x11 *packages* is an image issue. building in optional support for x11 in things is a distro feature. Sep 16 16:19:31 sgw: non-gplv3 can influence the distro settings, that is ok Sep 16 16:19:45 kergoth as a user, I would like an error if I try to use something that is disabled in an image or distro feature basis Sep 16 16:20:20 sgw: likely, the x11 pieces of avahi need to be packaged such that including avahi in an image doesn't pull in the x11 pieces automatically. Sep 16 16:20:42 X11 being built it you build avahi and have X11 enabled is just unfortunate Sep 16 16:20:44 kergoth: we want to include avahi in an image and not have it include the x11 (libglade bits), with the default DISTRO_FEATURES, that's not possible. Sep 16 16:21:40 RP__: Ok, I will look down that direction, not sure what it will take. Sep 16 16:24:38 I may have figured out the mystery multilib library problem.. :| Sep 16 16:25:01 the RPM per-file -provide- dependencies were not working right.. so NOTHING was providing library capabilities in the system today Sep 16 16:25:52 I am -shocked- this worked at all Sep 16 16:26:10 is there a simple way I can trigger the system to regenerate -all- of the rpm packages? Sep 16 16:29:08 fray: yes, rm tmp/stamps/*/*.do_package_write_rpm Sep 16 16:29:18 that will still reload from sstate though won't it? Sep 16 16:29:28 fray: oh, rm the sstate packages too Sep 16 16:29:42 they do have the task in the filename Sep 16 16:29:59 * fray just mv'd out of the way all of the tmp-eglibc and rm'd the sstate.. running a new build should be quick with the rest of the sstate in place Sep 16 17:24:00 sgw: er, are you sure about this? Sep 16 17:24:07 sgw: the avahi x11 thing Sep 16 17:24:29 sgw: the avahi gui stuff was split out into avahi-ui to fix this some time ago Sep 16 17:25:29 (although frankly I wonder if anyone actually uses the avahi gui functionality...) Sep 16 17:27:44 bluelightning: seems there more there still, that's one of the changes made when x11 was added to distro features. Sep 16 17:32:48 * RP__ heads afk for a bit Sep 16 18:28:50 BTW there is a serious problem with multilibs.. if you build, and then update/modify/add a glibc.. it no longer works.. things start failing in configure.. (this being toolchain components) Sep 16 18:34:13 bug 1490 Sep 16 21:47:08 how would one deal with multilib on an -sdk target? Sep 16 21:52:49 i should say, multilib gcc **** ENDING LOGGING AT Sat Sep 17 02:59:57 2011