**** BEGIN LOGGING AT Fri Dec 02 02:59:57 2011 Dec 02 06:25:20 gm Dec 02 06:25:48 mornin Dec 02 07:01:54 hmm, whats the defailt password for angstrom? I did not set anything but can't login via console on my freshly flashed self built OE core image...? Dec 02 07:10:40 damn... I can't login via serial and I wonder what package did tat to me Dec 02 07:12:50 check getty providers mingetty/util-linux-agetty/busybox/tinylogin Dec 02 07:13:00 Jin^eLD: and u-a Dec 02 07:14:04 tinylogin seems to be installed Dec 02 07:14:18 getty too, inittab uses getty Dec 02 07:15:04 and the getty link is right? Dec 02 07:15:26 it likns to tinylogin, yes Dec 02 07:16:40 one difference is that old has just "passwd" while new rootfs has "passw" and "passwd-" - shadow stuff? Dec 02 07:17:21 ah you see login: only the password is not accepted? Dec 02 07:17:27 right Dec 02 07:17:36 login as such seems to work, but password is not accepted Dec 02 07:17:46 ah then it's not getty's fault Dec 02 07:17:47 is OE setting any defaults and if yes where? Dec 02 07:23:07 hmm, where are the /etc/passwd* files in the rootfs coming from? opkg says they do not belong to any package Dec 02 07:24:15 Jin^eLD: iirc base-passwd creates them in postinst (during do_rootfs aready) Dec 02 07:24:29 that's why it's not owned by it Dec 02 07:24:37 but please check Dec 02 07:25:50 you are right Dec 02 07:25:51 thanks Dec 02 07:26:26 it does some trickery with it Dec 02 07:27:08 but I still can not figur eout where it is taking it from Dec 02 07:28:30 probably from the tarball, I think I get it now Dec 02 07:35:58 JaMa: regarding that DT_NEEDED thing Dec 02 07:36:23 JaMa: you need to specify it with the program that needs it Dec 02 07:36:26 I have successfully inserted a modules compiled from compat-wireless.org for D-Link DWA125 .... but now I m getting error as .... "phy3 -> rt2x00lib_request_firmware: Error - Failed to request Firmware." Dec 02 07:36:40 I have placed the correct firmware file in /lib/firmware................can anyone help me.... what I m missing..... ???? Dec 02 07:40:27 JaMa: so suppose a binary wanted a function from libA.so but did not do -lA but there was libB.so which has DT_NEEDED for libA.so and binary did -lB then so far behavour was that linker will implicitly link in libA.so to binary since it was in DT_NEEDED of libB which was spefied on linker cmdline with -lB Dec 02 07:40:33 but now it will fail Dec 02 07:40:46 and use has to supply -lA explicitly on cmdline Dec 02 07:41:03 in order to link the binary successfully Dec 02 07:41:49 logic is that tomorrow if libB.so removes its dependency on libA.so then this binary link will silently fail Dec 02 07:42:10 but if program B has B.pc or b-config, then -A should be stated there right? Dec 02 07:42:40 not fixed in program C which used pkg-config to discover B.pc needs or call b-config Dec 02 07:43:51 JaMa: if a symbol in binary depends directly on libA then it has to do -lA Dec 02 07:44:47 but for libB.so if it depends on libA.so providing it through pkgconfig will be required too Dec 02 07:45:38 ok then we think the same, thanks for confirmation Dec 02 07:45:46 JaMa: usually .pc/pkgconfig files are for libraries Dec 02 07:45:55 difference is when linking the binary Dec 02 07:46:03 the shared thing remains same Dec 02 07:46:26 I've sent first patch for such issue to meta-oe (nmon) but that was a bit special as ncurses was added only to LDFLAGS in recipe Dec 02 07:46:32 JaMa: but I see a problem here Dec 02 07:47:02 so if there is a program P which used symbols from libA and libB both Dec 02 07:47:11 and libB uses symbols from libA Dec 02 07:47:25 then you will export -lA in .pc file of B Dec 02 07:48:04 and when linking program P it will provide -lA to P's linking cmdline but it comes via libB's infrastructure Dec 02 07:48:20 that would be wrong since P should also have provision to link with libA.so Dec 02 07:49:24 yes that's why I'm not adding -lX11 to aurora-daemon when I expect it should come via some aurora-daemon dependency infrastructure (ie qt4 .pc) Dec 02 07:49:31 so tomorrow libB drops dependency on libA and stops exposing it through .pc file then program P can not be linked anymore Dec 02 07:49:40 so make sure this thing Dec 02 07:49:55 whoever needs the symbol has to provide -lblabla Dec 02 07:50:36 does aurora-daemon calls some functions from libX11.so directly ? Dec 02 07:50:50 no Dec 02 07:51:06 ok then it should not use -lX11 in its CFLAGS/LDFLAGS Dec 02 08:06:40 ich leg mich hin fuer ein paar stunden, bis nacher bzw dann bis am abend, hab euch ein mail geschrieben Dec 02 08:06:42 oops wrong window Dec 02 08:31:52 * khem -> sleep() Dec 02 08:33:24 gnight -> khem Dec 02 08:44:40 good morning Dec 02 10:01:39 RP__: Thanks for your response and sorry for the delay - I fell asleep and didn't check the IRC till now. :) Currently I'm trying to find out where the content for the -dbg packages is described. Dec 02 10:02:47 kenws: it seems RP__ hasn't seen your message, post it again Dec 02 10:06:16 otavio: yeah, it was yesterday. :) here is the corresponding irc log: http://paste.ubuntu.com/756885/ Dec 02 10:20:32 * kenws tries to add: FILES_${PN}-dbg += "${libexecdir}/getconf/.debug" Dec 02 11:06:55 hm, Ive been kicked from the oe-core mailing list ! Dec 02 11:08:14 i feel there is a list maintainer abusing his powers Dec 02 11:13:57 eFfeM_work: maybe it's just an error Dec 02 11:14:51 else that would give a very bad image of the OE community Dec 02 11:17:06 ericben, maybe, but maybe someone did not like my two cents: http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg12870.html Dec 02 11:20:18 pb_: appreciate you're looking into this Dec 02 11:25:13 eFfeM_work: If your suspicions should be based, would be a serious community problem Dec 02 11:26:30 hrm Dec 02 11:26:47 RP__: are you there? Dec 02 11:30:48 eFfeM_work: I think you should relax a bit the world is not against you, maybe that's just a technical issue on the mailing list server Dec 02 11:32:38 anyway I hope that was not deliberate else the means the OE community has a big problem Dec 02 11:33:51 we'll see. I've resubscribed. It is not *that* easy to get rid of me :-) Dec 02 11:35:04 eFfeM_work: LOL and moreover we still want you amid us :-D Dec 02 11:35:52 mckoan|away: thanks (hm pidging autcomplete seems to have an issue, might need to restart Dec 02 11:35:58 but first.... lunch ! Dec 02 11:35:59 bbl Dec 02 11:57:05 pb_: yes Dec 02 11:57:17 RP__: ah, hello. I just sent you an email. Dec 02 12:03:26 pb_: hmm, which address? Dec 02 12:03:32 RP__: your linuxfoundation one Dec 02 12:03:45 is there a better one to use? Dec 02 12:05:18 pb_: no, that one should work but it does bounce between a few systems after the LF server issues and it doesn't seem to have arrived yet :/ Dec 02 12:05:45 I am seeing other emails so I'm not sure why that one is going slowly Dec 02 12:05:54 ah. I'll give you the gist of it in a /query Dec 02 14:59:56 hi otavio Dec 02 16:00:43 hello! are source mirrors available at http://mirrors.openembedded.org/ ? It seems I cannot fetch from there Dec 02 16:03:46 afaik, no there are no source mirrors there, except for a limited number of packages.. Dec 02 16:04:02 both Angstrom and the Yocto project have mirrors available. (Yocto Project mirrors are limited to oe-core) Dec 02 16:04:47 Trying to build out of oe classic 2011.03-maintenance for da850-omapl138-evm Dec 02 16:05:08 missing tarball is fakeroot_1.14.5.orig.tar.bz2 Dec 02 16:05:51 this is known from http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-June/033363.html Dec 02 16:06:09 I -think- Angstom mirrors have that, but Im not sure.. sorry Dec 02 16:06:23 how to point to angstrom mirrors? Dec 02 16:06:40 not sure.. I've only used the Yocto mirrors myself Dec 02 16:08:43 I'll look into Yocto setup... any idea where they are setup? local.conf? mirrors.bbclass or similar? Dec 02 16:09:37 yocto has it in their configuration, but the mirror setup is simple.. Dec 02 16:09:45 let me point you to it.. just a sec Dec 02 16:09:58 thx Dec 02 16:11:13 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky.conf Dec 02 16:11:23 look at lines 42 - 55 Dec 02 16:11:44 premirrors.. do this before you try the upstream source.. mirrors = try this after you try the upstream source Dec 02 16:11:55 you can drop those lines into your local.conf file Dec 02 16:12:13 but it won't directly fix your issue.. AFAIK yocto doesn't have anything but the oe-core components.. so no fakeroot Dec 02 16:13:19 I will probably have to find Angstrom mirrors... Dec 02 16:20:45 gizero76: try INHERIT += "angstrom-mirrors" in your local.conf Dec 02 16:25:28 bluelightning: it doesn't work. I believe it was already set by including conf/distro/include/angstrom.inc Dec 02 16:25:39 I'm building angstrom-2010.x Dec 02 16:25:42 oh right Dec 02 16:25:57 looks like they also miss that tarball! Dec 02 16:30:42 ooops! http://www.angstrom-distribution.org/unstable/sources/ is pointing to a linux foundation web page (a broken one, I'd say)... Is it the same for you? Dec 02 16:30:59 d'oh Dec 02 16:31:05 yeah :/ Dec 02 16:31:14 unstable should point to the Yocto project? Dec 02 16:31:41 (I think.. from memory at least thats what i thought Koen said) Dec 02 16:33:08 http://www.angstrom-distribution.org/unstable/sources/pool/ looks more Angstrom-related, but no mirrored tarballs yet! Dec 02 16:34:05 how do i found out why a certain version of a recipe is beeing used ? Dec 02 16:34:45 I'll try later and see if it's back... i don't know either if it's supposed to come back! first time digging into this kind of problem with tarballs missing from upstream debian repos Dec 02 16:35:22 rob_w, bitbake -s will list all of the versions and if the "latest" isn't preferred, what the preferred version is.. Dec 02 16:35:29 that might answer some of your questions.. Dec 02 16:36:42 ok cool Dec 02 17:14:13 how can I keep bluez4 or any bluetooth stuff from being built? Dec 02 17:23:57 sgw: what exactly are your CONSOLIDATED PULL vs. a normal patch you post? Dec 02 17:24:14 sgw: it seems like you are just reposting others patches for the record? Dec 02 17:27:41 msm: the idea is that I am pulling together patches and testing them as a group before RP pulls. Dec 02 17:28:17 msm: sometimes this works better than others. I was under the weather this week, so RP pulled directly. Dec 02 17:29:20 so that is a test run for the autobuilder? Dec 02 17:29:24 sgw: ^ Dec 02 17:31:10 yes, sometimes on the external one, we also have some internal machines that I use. Dec 02 17:37:09 i cant find the recipe which forces me on gcc-4.3.3 ( its an old snapshot) .. how do i identify any recipe bringing in this version condition Dec 02 17:37:35 the reason is i want to use gcc-4.5 now . maybe , can i force gcc to be anything but 4.5 ? Dec 02 17:45:45 I asked this the other day - do we have any interest in have a host-prepare script? Something that runs yum or apt to install required host packages? Dec 02 18:01:43 msm: this has been talked about before, I think the answer would be yes, I remember one discussion about adding a package that would add the a repo via a web download. Dec 02 18:41:13 msm: its something we should think about Dec 02 18:41:47 msm: we have to sanitize distro's packages which are deemed good then should be added to ASSUME_PROVIDED Dec 02 18:42:16 that can avoild lot of native builds Dec 02 18:50:38 khem: have you seen my auto assume provided? less manually sanitized, but I've been using it for builds for months Dec 02 19:01:00 sgw: khem: well, i'll ask my coworker to send a patch to Dec 02 19:01:12 kergoth: is this in the tree currently? Dec 02 19:01:30 nah, it's in my ~/.oe, which I have in my BBPATH in bblayers.conf in all my setups Dec 02 19:01:33 for my local / site specific bits Dec 02 19:01:57 since it could *potentially* break, figured it being default would be bad. guess we could try throwing it to meta-oe but leave it opt-in Dec 02 19:09:20 kergoth: its interesting… anything to speed up builds is good Dec 02 19:09:40 its such a huge turn off for people just getting started with OE Dec 02 19:10:26 that and disk size… almost of people run these things on laptops in VMs Dec 02 19:15:08 * kergoth nods Dec 02 19:15:17 it hurts when comparing oe to something like buildroot Dec 02 19:15:22 or even ltib, to a lesser extent Dec 02 19:15:55 i know Dec 02 19:16:00 but thats the comparison that gets made Dec 02 19:16:38 https://bitbucket.org/kergoth/dotfiles/src/ad1537b9002d/oe/classes/assume.bbclass and https://bitbucket.org/kergoth/dotfiles/src/ad1537b9002d/oe/lib/kergoth Dec 02 19:16:54 (experimenting with hg for my dotfiles as an excuse to force myself to get as comfortable with hg as I am with git) Dec 02 19:20:29 kergoth: how much does this improve the first pseudo-native build step? Dec 02 19:21:35 not sure, haven't done much performance testing with it Dec 02 22:13:55 has anyone looked at using a common components for the linux source Dec 02 22:14:05 when building packages for each MACHINE Dec 02 22:14:20 the kernel sstate-cache components tend to take up 200mb each Dec 02 22:14:29 seems like each one of these would have a lot of overlap Dec 02 22:31:13 nevermind, im just wrong… its not common stuff Dec 02 22:40:50 khem: ping Dec 02 22:41:51 ant____: hello Dec 02 22:42:52 hi there Dec 02 22:43:51 there is a starnge breakage reported crosscompiling on ubuntu Dec 02 22:44:01 do you build on 11.10 ? Dec 02 22:45:47 khem: seemsm having to do with linaro Dec 02 22:45:50 https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/872426 Dec 02 22:46:29 now, that's very strange, provided you sent a patch in OE which went upstream one year ago... Dec 02 22:47:05 maks, klibc maintainer, said 'i think they have a semistrange multiarch patch.' Dec 02 22:49:30 ant____: hmm possible Dec 02 22:51:04 in fact the patch was fixing build on native i386 Dec 02 22:51:11 http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=28da73a8add68f4abf68c417ac9559acc5d06861 Dec 02 22:51:56 that guy does not have kernel headers staged **** ENDING LOGGING AT Sat Dec 03 02:59:57 2011