**** BEGIN LOGGING AT Fri Sep 09 02:59:57 2011 Sep 09 08:23:21 RP__: morning and ping Sep 09 08:23:30 hi dongxiao Sep 09 08:25:21 RP__: I met several multilib issues related with package architecture. for the "all" architecture, I saw we add a new allarch.bbclass to handle them, however not all the "all" packages inherit that bbclass, could you help to explain why? Sep 09 08:26:18 dongxiao: Some packages marked as "all" have dependencies on the compiler for example which means technically they're not "all" architecture Sep 09 08:26:31 dongxiao: I only got about half way through sorting them out Sep 09 08:26:53 RP__: so shall we remove those "PACKAGE_ARCH=all" for those recipes? Sep 09 08:27:49 dongxiao: In some cases we might remove the configure pieces that are calling into the toolchain as they might not be needed Sep 09 08:29:11 RP__: I got your point. we may need such changes for rpm multilib support Sep 09 08:29:55 RP__: will these changes acceptable for 1.1 release? Sep 09 08:30:17 dongxiao: Hmm, right :/ I had hoped we'd managed until post 1.1 with those Sep 09 08:32:37 RP__: so for confirm, we need them for 1.1? Sep 09 08:33:44 dongxiao: Well, you say you're hitting multilib issues. I'm not sure exactly what you're hitting or how much of a problem it is Sep 09 08:35:20 RP__: with qemux86-64 machine, currently under tmp/deploy/rpm folder, we have all, x86-64, and qemux86-64 folder, then if we build a lib32 version of "all" arch recipe, then the new 32bit rpm will override the 64bit rpm package Sep 09 08:36:48 dongxiao: unless it uses the allarch class? Sep 09 08:39:56 dongxiao: I'm not sure what the best solution here is going to be give then time constraints Sep 09 08:40:16 .RP__: if use all arch, the multilib_global.bbclass will raise exception Sep 09 08:40:45 dongxiao: What kind of exception? Sep 09 08:42:25 RP__: it is in f9c3639238c2a9f1072e39ba26d0e521c5951b95 Sep 09 08:45:43 dongxiao: I can't find that hash... Sep 09 08:46:30 RP__: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f9c3639238c2a9f1072e39ba26d0e521c5951b95 Sep 09 08:49:09 dongxiao: So you want to back out the allarch part of that change? Sep 09 08:50:43 hi RP, I got an issue and need your help. :-) The issue is similar to bug 1388: in task-core-boot.bb, RDEPENDS_task-core-boot has VIRTUAL-RUNTIME_update-alternatives, and I'm changing this variable to make it depend on IMAGE_PKGTYPE: for deb, the variable is 'update-alternatives-dpkg' and for ipk, it's 'update-alternatives-cworth'. My issue is: the change causes trouble to sstate -- i.e., when I build from scratch with ipk, the xxx_package.tgz in sstate-cache Sep 09 08:51:32 RP__: Maybe it is a choice. if we back out that change, we need to change the lib32 version of all archs PACKAGE_ARCH to avoid duplication. since both of those rpm name is "update-rc.d-0.7-rc4.all.rpm". (Take updte-rc.d as an example) Sep 09 08:51:33 dcui: Why can't we always use the cworth version? Sep 09 08:52:17 dongxiao: Don't these packages both have the same set of files in them? Sep 09 08:52:35 RP__: looks dpkg needs the -dpkg version(?) Sep 09 08:52:54 dcui: Why? Sep 09 08:53:13 RP__: the cwoth version causes a failure, I didn't remember it... Sep 09 08:53:18 RP__: I'll find it out. Sep 09 08:53:57 dcui: I think the original intention was to default to cworth for both. If the cworth version can't work then we can rethink that but I'd like to understand why Sep 09 08:54:37 RP__: yes they are the same. but to solve bug 1457, we may need to add architecture information in rpm's spec file to differentiate x86 and x86_64 version of packages. like "Provides: update-rc.d.x86-64" Sep 09 08:54:45 RP__: got it. Sep 09 08:55:44 dongxiao: Isn't this why we have an "all" arch which is compatible with both? Sep 09 08:56:12 dongxiao: The objective should be just to have one of these, not two... Sep 09 08:58:26 RP__: yes. you are right, I should use update-rc.d as an example above for "Provides: ", as for update-rc.d, it should be ended with ".all" Sep 09 08:58:54 RP__: I mean I SHOULDN'T use update-rc.d as an example Sep 09 08:59:28 dongxiao: right Sep 09 09:00:08 RP__: OK, so even they will override, there should be no problem for all architecture. Sep 09 09:00:23 RP__: another issue is the MACHINE_ARCH in PACKAGE_ARCHS Sep 09 09:00:30 dongxiao: Yes. its not brilliant that it would happen but they should be the same thing Sep 09 09:01:30 RP__: currently we have all, x86-64, and qemux86-64 in normal PACKAGES Sep 09 09:02:32 RP__: enable multilib, there will be a new "x86" under tmp/deploy/rpm due to the setting of DEFAULTTUNE_virtclass-multilib-lib32. Sep 09 09:03:21 RP__: but we still need a new multilib ${MACHINE_ARCH}, like qemux86 created due to multilib setting Sep 09 09:03:41 RP__: currently we don't have that kind of mechanism. Sep 09 09:03:54 dongxiao: sounds like we need to prefix MACHINE_ARCH with MLPREFIX Sep 09 09:05:29 RP__: yes that's one solution. or can we set something like MACHINE_virtclass-multilib-lib32 = "qemux86" in local.conf and override the MACHINE_ARCH when setting MULTILIB_PACKAGE_ARCHS? Sep 09 09:07:05 dongxiao: Since the path layout is different between qemux86-64 and qemux86 I'm not sure that would be a good diea Sep 09 09:08:51 RP__: ok, I think you are right, so we will have all, qemux86-64, lib32-qemux86-64, x86-64 and x86 directories under tmp/deploy/rpm. Sep 09 09:09:04 dongxiao: yes Sep 09 09:09:27 RP__: Thanks for the discussion, I will follow that way. Sep 09 09:11:22 dongxiao: np Sep 09 09:40:24 hi all Sep 09 09:45:49 morning Sep 09 12:12:12 RP__: ping Sep 09 12:12:23 dongxiao: pong Sep 09 12:13:19 RP__: I still have a question about the MACHINE_ARCH. if we add MLPREFIX before that, what's the lib32 version of rpm file name like? pn-pv-pr-lib32-qemux86_64.rpm? Sep 09 12:13:49 RP__: it seems that the architecture information in the rpm filename could not contain '-' symbol Sep 09 12:16:22 dongxiao: - gets translated to another character within rpm from what I remember Sep 09 12:17:02 dongxiao: The rpm name is likely the same anyway, just set to a different architecture and contained within a different directory Sep 09 12:20:16 RP__: ok. thanks. I will try if using lib32-qemux86-64 as arch info works. Sep 09 13:41:01 RP__: Hi Richard, for a "all" package, it shouldn't require x86-64 arch package, right? Sep 09 13:57:24 RP__: ping Sep 09 14:21:03 dongxiao: pong, sorry, was busy on another window Sep 09 14:21:17 dongxiao: correct, it shouldn't Sep 09 14:23:52 RP__: ok, we may need to fix several "all" recipes since they may require "xxx.x86-64" in normal case and require "xxx.x86" in multilib case. Sep 09 14:25:26 dongxiao: They're the same recipe so they should just be "xxx.all" ? Sep 09 14:28:03 RP__: yes, that's depends on "all" recipes depends on "all" recipes. But we have some "all" recipes RDEPENDS on "x86-64" package, which is not correct, so there will be "Requires: xxx.x86-64" in spec file. Sep 09 14:29:08 RP__: a little tricky, take x11-common as an example, its PACKAGE_ARCH is "all", however it RDEPENDS on dbus. so I think its PACKAGE_ARCH SHOULDN'T be "all" Sep 09 14:29:50 dongxiao: right, if that is the case we need to stop them being "all" arch packages Sep 09 14:30:27 RP__: OK. During multilib bug fixing, I will find out those "all" recipes and fix them accordingly. Sep 09 14:30:35 although it depends on what the dbus dependency is I guess. If its a general dependency it might be ok, an shlibs one would not be though Sep 09 14:31:26 dongxiao: I'd really need to look at the examples to figure out what should happen Sep 09 14:33:45 RP__: Thanks:) Sep 09 16:25:36 hi, I've an issue with QT4: with nativesdk in oe.dev we had qmake -v => Using Qt version 4.7.1 but in /usr/local/angstrom/arm/lib but in oe-core there is: qmake -v => Using Qt version 4.7.3 in /home/denis/oe/angstrom-core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/lib Sep 09 16:40:28 hi, concerning GNUtoo|work problem : this is when building meta-toolchain-qte. It seems that in openembedded-core qmake integrates the path of the sysroot in tmp build dir instead of having the path of the target directory where the sdk will be extracted Sep 09 16:41:09 this was previously working fine with oe.dev. Do you have any idea of where to start looking for the problem is oe-core ? Sep 09 16:43:25 the problem may be in meta/recipes-qt/qt4/qt4-tools-nativesdk.inc but we didn't find any obvious difference vs oe.dev, except the inherit nativesdk qmake2 instead of inherit sdk Sep 09 16:48:58 only thing i can think of is to look at the qmake recipe and see if there is something different in them Sep 09 16:49:49 fray: there is no qmake recipe, it's in qt4-tools-nativesdk Sep 09 16:50:04 ahh.. Sep 09 16:50:07 I don't know then sorry Sep 09 16:53:58 thanks for having an idea that's what we are looking for to progress on this ;-) Sep 09 17:00:55 fray: If we're running a command like "sudo xxx" and pseudo is active but disabled in memory, is there a way to stop it complaining about the LD_PRELOAD not being possible? Sep 09 17:01:19 no, because the complain is coming from sudo or ld.so Sep 09 17:01:52 the only thing that could be done is to clear LD_PRELOAD.. but I think pseudo will automatically add it back into the nevironment on a fork/exec Sep 09 17:01:53 fray: but there is also no way to unset the LD_PRELOAD? Sep 09 17:02:01 fray: right, it will add it back Sep 09 17:03:51 ther eis no way to prevent it from resetting LD_PRELOAD Sep 09 17:03:57 I just checked the code, it does it unconditionally Sep 09 17:04:15 fray: ok, I'll redirect stderr :/ Sep 09 17:04:28 won't work.. it's not fed to stderr by ld.so Sep 09 17:04:39 (at least it won't on some versions of ld.so) Sep 09 17:05:07 fray: well, its working in this case at least which is better than nothing I guess Sep 09 17:06:30 what needs both pseduo and sudo? Sep 09 17:08:54 fray: automated QA tests within yocto builds setting up the tun/tap devices Sep 09 17:09:25 'k.. so it's not something a normal user would encounter Sep 09 17:09:31 fray: Its a corner case I noticed while trying to fix other things Sep 09 17:24:03 why was creating tar balls from ie git checkout droped in fetch2? (it still does tarballs for whole repository, but not anymore for exact SRCREV only) Sep 09 17:29:47 JaMa|Off: you can enable it Sep 09 17:30:10 JaMa|Off: i don't recall the variable but it is possible to enable it back Sep 09 17:34:42 otavio: if you mean BB_GENERATE_MIRROR_TARBALLS then this controlls only whole repository tar balls not for each checkout Sep 09 17:35:19 JaMa|Off: yes; now I see what you meant Sep 09 17:36:31 otavio: and it seems that it doesn't even try to download exact checkout first.. Sep 09 18:19:45 RP__ thinking aobut teh pseduo thing.. setting PSEUDO_RELOADED=YES -might- allow you to unset the ld-preload Sep 09 18:19:58 (not really what it's intended for BTW) Sep 09 18:20:12 I suspect what we need to do is add a flag that unloads pseudo on the next exec Sep 09 18:52:52 * kergoth__ looks into killing sysfsutils deps from oe-core, since it seems to be deprecated entirely in favor of libudev Sep 09 18:53:35 sheesh, last stable release was 2006 Sep 09 18:55:41 sysfsutils is still useful for identifying bus topologies and such.. but it shouldn't be used by anything processing dynamic events Sep 09 18:56:02 I'm somewhat surprised there are deps on sysfsutils Sep 09 18:56:35 pcmciautils, directfb, iputils, at the moment. pcmciautils dropped the dep in git, but not yet in a release. iputils still uses it for arping, but there's a standalone arping we could grab instead, though it deps on libnet/libpcap Sep 09 18:56:48 looks like you can opt out of its usage for directfb fbdev and let it use proc instead Sep 09 18:56:49 hmm Sep 09 18:57:06 Hmm.. I didn't realize those all still used it Sep 09 18:57:26 directfb falling back to proc sounds dangerous to me.. but I'm not sure Sep 09 18:57:40 (does anyone still use pcmciautils?) Sep 09 18:58:52 Older devices probably still use it for compactflash, but I don't know if that's something the core needs to support or not Sep 09 18:58:54 ...and does udev provide the equivalent library functions that could be mapped? Sep 09 18:59:15 it's worth asking on the oe-core list.. I'd be more then willing to say it should be in meta-oe instead Sep 09 18:59:26 I can't think of any recent systems where it'd be needed Sep 09 18:59:57 http://www.signal11.us/oss/udev/ - looks promising Sep 09 19:00:10 will email about it then, thanks Sep 09 19:01:13 ya swtiching to libudev makes more sense to me -- if the interfaces are reasonably similar (and I can't imagine they're not) Sep 09 19:01:23 agreed Sep 09 19:03:26 sounds like arping is really the only candidate there.. sysfsutils might still be needed in that case if udev isn't available.. Sep 09 19:03:45 (udev is a pig -- perforamnce wise if you are attempting fast boot and have a static device) Sep 09 19:07:41 true, though I doubt arping is needed by all that many, could argue for putting the separate arping in meta-oe and dropping it from oe-core iputils Sep 09 19:07:57 though, could add the separate arping to oe-core too, if it really is needed Sep 09 19:07:59 hrm Sep 09 19:08:09 * kergoth__ wanders off for a bit Sep 09 19:08:12 I know people building certain types of routers and fail-over devices use it.. but beyond that I dunno **** ENDING LOGGING AT Sat Sep 10 02:59:58 2011