**** BEGIN LOGGING AT Mon Dec 19 02:59:58 2011 Dec 19 12:45:06 RP__: any idea why sometimes messagebus is completely missing in images /etc/group with latest opkg? Dec 19 12:45:20 RP__: even after rebuilding dbus **** BEGIN LOGGING AT Mon Dec 19 12:51:54 2011 Dec 19 16:10:05 fray: is it expected that the "requires" list for a package as reported by rpm -q -qf includes the items from the "suggests" list for the package as well? Dec 19 17:41:46 fray: ping Dec 19 17:50:47 hey Dec 19 17:51:23 fray: hi mark, is it expected that the "requires" list for a package as reported by rpm -q -qf includes the items from the "suggests" list for the package as well? Dec 19 17:52:01 yes. When you simple ask PRM what is required. it list both hard and "soft (hint)" requirements.. Dec 19 17:52:08 you need to query it for the flags as well Dec 19 17:52:28 ah right, how does one do that easily? Dec 19 17:52:39 I don't remember off hand... Dec 19 17:53:06 ok... my other workaround was going to be to get the suggests list and filter those out, but that's a pain to do in shell script Dec 19 17:53:27 ya there is a way to do it vira the query methods.. let me see if I can find it Dec 19 17:57:12 fray: got it - rpm -q --qf "[%{REQUIRES} %{REQUIREFLAGS}\n]" Dec 19 17:57:21 now, to work out what the flag values mean Dec 19 17:57:38 there is a way to turn the flags into text BTW Dec 19 17:57:52 now to figure that out.. ;) Dec 19 17:59:35 can you try querying %{suggests}? Dec 19 17:59:55 fray: yeah that works but then I need to subtract one list from another Dec 19 17:59:58 I believe that is an alias.. but I'm not sure.. Dec 19 18:00:06 http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch04s02s10s05.html Dec 19 18:00:14 it won't be in that.. Dec 19 18:00:19 least not that I know of Dec 19 18:00:33 the above link suggests %{REQUIREFLAGS:depflags} but it does not work with our rpm Dec 19 18:01:17 I doubt it works either their vesion either.. :P Dec 19 18:02:48 Hmm.. I swear there was a way on the command line to query the hints.. but I'm not seeing it Dec 19 18:03:09 they bit BTW is RPMSENSE_MISSINGOK 1<<19 Dec 19 18:04:22 does ":fflags" work for you? Dec 19 18:04:34 it should print an "m" for hinted packages.. but I'm not sure it's right Dec 19 18:05:25 fray: it does print m for some, but not for the packages I expect to be "hinted" Dec 19 18:05:51 ya, I agree.. Hmm.. Dec 19 18:06:03 fray: http://pastebin.com/uxwgJz9U Dec 19 18:06:04 you're going to have to ask on the rpm5 mailing list -- or ty #rpm here on IRC Dec 19 18:06:19 connman-plugin-* aren't hard dependencies Dec 19 18:06:45 ya.. something is up w/ the flagging Dec 19 18:06:52 fray: ok, thanks Dec 19 18:07:07 it may simply be we have to extend RPM to print hte hint flagging.. Dec 19 18:07:16 I have a rough understanding of where to do it in the code.. Dec 19 18:07:23 (it may also be our version of rpm is too old to have it) Dec 19 18:35:22 zeddii, poke - wondering where things are with allnoconfig support? Dec 19 18:35:44 zeddii, trying to sort out what to do with the poky-tiny distro definition for master _now_ as we don't yet have the 3.2 kernel there Dec 19 18:36:07 zeddii, I can do recipe-space config until we have the new tooling in place... but wanted to make sure we were on the same page there Dec 19 18:37:20 dvhart, I'm deep in tearing apart patching support. knarly stuff. and then I'm finishing what I started on the allnoconfig, requires/optional kconf support. ETA is a few days. I'm finally making progress, but seeing some really head scratching results at the moment. but this is all that I'm working on, so it's moving. Dec 19 18:38:03 zeddii, OK, I'm hoping to get initial poky-tiny submitted today Dec 19 18:38:13 zeddii, so I'll do recipe-space qemux86* support for now Dec 19 18:38:20 and we can integrate with the updated tooling in the new year Dec 19 18:38:46 sounds good. no biggie there. I'll have all the parts put together shortly (but not that shortly) .. I'm over the learning curve now. Dec 19 18:56:03 poky-tiny? is it similar to micro? Dec 19 18:58:42 kergoth, yes Dec 19 18:59:15 kergoth, this is the result of some work I was doing to minimize the rootfs and the kernel images we build Dec 19 18:59:48 dvhart: and how much smaller did you get to Dec 19 19:00:07 khem, I got as small as 2.2 MB for both bzImage and rootfs Dec 19 19:00:21 but 4M is a more realistic (ie usable) images Dec 19 19:00:59 * dvhart is digging up the URL to the slides Dec 19 19:01:00 dvhart: in classic OE there was uclibc+busybox static linked image + kernel around 2M Dec 19 19:01:18 khem, are you referring to meta-micro? Dec 19 19:01:33 dvhart: not particularly to micro Dec 19 19:01:37 since it was an image Dec 19 19:01:52 I once generated it using slugos distro Dec 19 19:01:54 it was a distro definition (two actually) as well Dec 19 19:02:16 and uclibc and busybox were not chopped Dec 19 19:02:31 I guess if one did chop those then it could be even smaller Dec 19 19:03:10 it was roughly 1.2M kernel 0.8M rfs Dec 19 19:03:22 yup, that's consistent with what I'm seeing as well Dec 19 19:03:38 are you using uclibc too ? Dec 19 19:03:53 * zeddii is suffering death by python incompetence today Dec 19 19:03:59 The libc is user selectable wtill with TCLIBC Dec 19 19:04:04 I would like to see how small eglibc can get Dec 19 19:04:06 I built both eglibc and uclibc Dec 19 19:04:12 ok Dec 19 19:04:29 khem, eglibc can get you down to 4MB kernel+rootfs images before you start to hack off limbs Dec 19 19:04:37 (ie it starts getting rather useless) Dec 19 19:04:45 with eglibc you cant build static rootfs reliably Dec 19 19:04:52 thats what I would expect Dec 19 19:05:01 what do you mean? Dec 19 19:05:18 since smallest I eglibc I could get was around 1M and then you have to have busybox Dec 19 19:05:51 http://events.linuxfoundation.org/events/embedded-linux-conference-europe/hart Dec 19 19:05:53 dvhart: eglibc/glibc assumes shared linking Dec 19 19:06:01 so there are cases where it wont work Dec 19 19:06:23 bah that link is useless Dec 19 19:06:35 http://elinux.org/images/2/2b/Elce11_hart.pdf Dec 19 19:06:37 there we go Dec 19 19:06:55 that was summaries of 4 or 5 different ways I built up a "meta-tiny" images Dec 19 19:07:07 I'm working on integrating those ideas into a poky-tiny Dec 19 19:08:10 slide 41 has the image size summary Dec 19 19:08:33 http://www.youtube.com/watch?v=WHLvI8j31vk if you want to see the video of that talk Dec 19 19:09:08 Huh, I didn't know it made YouTube :) Dec 19 19:09:55 yeah I stumbled across them the other day Dec 19 19:10:15 I imagine I'm in the community bof one but I'm not sure I want to view it to find out :) Dec 19 19:10:25 free electrons has them in HD as well Dec 19 19:10:29 http://free-electrons.com/blog/elce-2011-videos/ Dec 19 19:10:46 yeah that's definitely better Dec 19 19:11:19 not that I'm encouraging anyone to spend an hour watching me :) Dec 19 19:13:10 dvhart: yeah I wonder why we could not drop libcrypt with eglibc e.g. Dec 19 19:13:29 but I think thats not that much of a gain Dec 19 19:13:43 27k :) Dec 19 19:14:04 the bulk is still in libc, at > 1M Dec 19 19:14:31 and nis Dec 19 19:15:04 oh well we do have uclibc for below certain mark Dec 19 19:15:06 I don't recall Dec 19 19:15:27 I think using static nss maps might make it go away I dont know Dec 19 19:15:53 thanks for the thought, I'll appreciate your thoughts on the patch series Dec 19 19:16:10 I'm sure we will continue to whittle -tiny down once it gets in Dec 19 19:16:36 Most of what I've been doing is uncovering bugs while moving from a layer to a distro definition Dec 19 19:16:48 so it will be called poky-tiny or somesuch ? Dec 19 19:17:11 yes uncovering bugs is common Dec 19 19:17:20 I happen to fix things before the real fix Dec 19 19:17:39 khem, I don't really care what we call it, but yes the current distro title is poky-tiny Dec 19 19:18:13 the linux-yocto recipe will be undergoing some surgery to support the kernel changes properly as well Dec 19 19:18:16 as a second stage Dec 19 19:18:20 dvhart: my main question was it will be a separate distro and not kludges into existing distro Dec 19 19:18:28 correct Dec 19 19:18:33 the way we did it in classic oe was scaling the distro Dec 19 19:18:35 that seemed to be the best approach Dec 19 19:18:38 which was wrong Dec 19 19:19:15 Did u use mdev or udev ? Dec 19 19:19:35 with mdev one can get rid of udev Dec 19 19:19:44 I'm actually just using devtmpfs for now Dec 19 19:19:53 I started with mdev though Dec 19 19:20:18 i c Dec 19 19:20:20 I don't know that mdev or udev really have much to offer for the tiny image use cases Dec 19 19:21:01 but, they can be added by overriding the VIRTUAL-RUNTIME_dev-manager Dec 19 19:21:03 they dont usually but in some cases e.g. NSLU devices they still wanted it Dec 19 19:21:14 since they could plug anything into the damn USB port Dec 19 19:21:16 right, I think tiny should default to small Dec 19 19:21:26 and people can build up Dec 19 19:21:32 rather than try to cut it back further Dec 19 19:21:43 yes Dec 19 19:21:45 with the exception of some core things that I don't feel we should cut out Dec 19 19:21:47 good work though Dec 19 19:21:51 like networking support Dec 19 19:21:58 that's cheating Dec 19 19:22:24 yes networking infact wireless stack as well :) Dec 19 19:22:33 you think wireless too? Dec 19 19:22:33 hrm Dec 19 19:33:11 I wonder how does linux-yocto picks the default .config for a machine Dec 19 19:34:11 khem, it uses the branch config and merges in the bsp config as well as any features named in the recipe itself Dec 19 19:34:27 it needs a new "tiny" base config Dec 19 19:34:46 the branching and config/feature stacking/inheritance needs updating as well Dec 19 19:34:53 zeddii and I have been hashing that out Dec 19 19:35:02 dvhart: so when I say qemuarm then it already knows its an armv5 machine Dec 19 19:35:13 correct Dec 19 19:35:23 dvhart: ok thanks thats what I thought Dec 19 19:39:13 * zeddii declares victory over inline python and starts cleaning up. Dec 19 19:39:29 zeddii, congrats :) Dec 19 19:39:50 * dvhart is wondering why after specifying yocto/standard/base that linux-yocto-tiny checks out yocto/standard/common-pc/base Dec 19 19:39:55 yocto/standard/arm-versatile-926ejs Dec 19 19:40:04 khem, right Dec 19 19:40:13 hmm so how does it map it to this branch Dec 19 19:40:19 is there some token in machine.conf Dec 19 19:40:30 arm-versatile-926ejs = qemuarm Dec 19 19:41:14 dvhart, I've been 4 days trying to fix the patch ordering issue you randomly found. @#$ .. but alas, I think I have it found now. Dec 19 19:41:35 4 days ??!?!!?! Dec 19 19:41:38 geez Dec 19 19:41:44 sorry man Dec 19 19:41:54 I've been all through patch.bbclass, and the bitbake fetching code. factoring out parts .. etc, etc. Dec 19 19:41:58 but I know how it works now :P Dec 19 19:48:29 dvhart: in qemumips.conf I see #@DESCRIPTION: mti_malta32_be Dec 19 19:48:44 is that info used by kernel tooling to select the config branch Dec 19 19:48:55 or say the machine branch in linux-yocto Dec 19 19:49:05 I don't believe so Dec 19 19:49:12 that should be set in the linux-yocto recipes Dec 19 19:49:17 by KMACHINE= Dec 19 19:49:43 random cruft. that's the actual machine under the covers though. Dec 19 19:49:44 of course, that is also what I'm trying to hunt down as well for qemux86 which I can't seem to prevent from selecting common-pc Dec 19 19:50:04 bruce where is is KMACHINE defined? Dec 19 19:50:18 in the specific kernel recipes. Dec 19 19:50:21 linux-yocto-tiny.bb sets it and the _qemux86 override to standard/base Dec 19 19:50:27 or in the appends. Dec 19 19:50:35 and yet bitbake -e reports common-pc Dec 19 19:50:37 grmble Dec 19 19:50:47 that is the kmachine for qemux86 :) Dec 19 19:50:54 it shouldn't be Dec 19 19:50:55 hello ppl Dec 19 19:51:03 not after I set it to standard/base ! Dec 19 19:51:21 linux-yocto_3.0.bb Dec 19 19:51:23 has it Dec 19 19:51:26 you know of any documentation where I can find out how to build an image using yocto for a mini2440 board? Dec 19 19:51:32 KMACHINE_qemuarm = "yocto/standard/arm-versatile-926ejs" Dec 19 19:51:34 dvhart, it's what I said before Dec 19 19:51:36 KMACHINE_qemux86 = "yocto/standard/common-pc/base" Dec 19 19:51:44 I though we changed those to ?= Dec 19 19:51:53 ah Dec 19 19:52:01 where is that set though? Dec 19 19:52:13 so kernel overrides it in hard way Dec 19 19:52:14 I am not bbappending linux-yocto_3.0.bb, I just include the linux-yocto.inc Dec 19 19:52:24 and create a new linux-yocto-tiny_3.0.bb Dec 19 19:52:34 and the .inc doesn't set the KMACHINE Dec 19 19:53:02 that's a bitbake question then. is it parsing the linux-yocto_3.0.bb anyway. Dec 19 19:53:08 and then setting the variable ? Dec 19 19:53:13 if I have to add a new machine to linux-yocto then it has to come through the tree then right ? Dec 19 19:53:21 I mean linux-yocto tree Dec 19 19:53:51 that's the best place for it yes, but see Tomz's email from this morning and the docs. you can define boards out of tree. Dec 19 19:53:52 not a patch on top of existing sources for the tooling to work Dec 19 19:54:15 hmm Dec 19 19:54:28 khem, I usually start out of tree and get it working, then push it in Dec 19 19:54:40 this isn't ideal right now without zeddi's current patch fixes Dec 19 19:54:49 especially for config Dec 19 19:54:52 * zeddii weeps at his python code. Dec 19 19:54:59 can't yocto be used for a mini2440 board? regarding machines, I only discovered qemu machines or beagle, no other arm specific machine I can base off Dec 19 19:55:03 am I wrong? Dec 19 19:55:29 s0undt3ch, yocto has 4 example hardware MACHINEs defined, one per arch Dec 19 19:55:39 other layers are available that define new boards Dec 19 19:55:43 such as meta-intel Dec 19 19:56:00 dvhart: dam, I as unable to find about those Dec 19 19:56:17 * zeddii smiles. dvhart as a side effect, you'll be able to simply add a .scc in the src_uri and not the patches. Dec 19 19:56:19 s0undt3ch, they are defined in the meta-yocto/conf/machines directory Dec 19 19:56:21 how could I specify my arm machine then? or find out the available ones? Dec 19 19:56:28 zeddii, excellent! Dec 19 19:57:11 yes, finally. now I can finish everything else pretty quickly. I've been on this like a dog with a bone. I couldn't switch my focus. Dec 19 19:57:29 zeddii, know how that goes Dec 19 19:57:59 s0undt3ch, checkout the documentation on the yoctoproject website Dec 19 19:58:04 s0undt3ch, for example, http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Dec 19 19:58:07 seriously. I was tunnel vision there for a bit, knowing that I needed to get my M2 stuff done. now I can. and enable pretty much what we were shooting for. phew. Dec 19 19:58:10 dvhart: know any layer related to the 2440? Dec 19 19:58:23 s0undt3ch, I'm not familiar with that particular board Dec 19 19:58:35 k, Thanks Dec 19 19:58:42 s0undt3ch: there is no layer supporting that device that I know of Dec 19 19:58:51 s0undt3ch: you can create one if you like Dec 19 19:59:00 khem: I will need to Dec 19 19:59:07 but I'm very new to all this Dec 19 19:59:20 basically it will be a forward port from oe.dev Dec 19 19:59:47 s0undt3ch: there is lot of docs out there on creating BSPs Dec 19 20:00:09 see yocto's website and also some docs on oe website which will explain some parts Dec 19 20:03:53 hmmm sshd dies on qemuppc and does not restart Dec 19 20:14:22 * zeddii is in shock. it just worked. Dec 19 20:14:39 * zeddii steps away and then will cleanup and send it out. then get dvhart's foo done as well. Dec 19 20:49:38 is there an official yocto project supported package repository (either zypper or opkg)? Dec 19 21:09:20 * zeddii has to go listen to some kids sing. back online later. Dec 19 21:10:05 sakoman__, no, we don't maintain binary package feeds Dec 19 21:35:03 zenlinux: OK, thanks. I'll set up one of my own then. **** ENDING LOGGING AT Tue Dec 20 02:59:57 2011