**** BEGIN LOGGING AT Wed Mar 27 02:59:58 2013
Mar 27 08:19:03 <mckoan> good morning
Mar 27 08:28:48 <neg> Hi, i have a .bbappend file to the kernel where i add the option CONIFG_IGB=m is there anyway that i in the same .bbappend file can add kernel-module-igb to the lists of packets to be included in the image? Now I have to add it to my local.conf IMAGE_INSTALL_append list
Mar 27 09:24:39 <bluelightning> morning all
Mar 27 11:13:27 <erbo> So what's the way to choose init manager now (for a distro)? Seems like DISTRO_FEATURE_INITMAN is not used in master anymore
Mar 27 11:15:30 <erbo> oh, nevermind.. It was well explained in packagegroup-core-boot
Mar 27 11:52:19 <rburton> erbo: VIRTUAL_RUNTIME_init-manager, after adding the systemd distro feature if that's what you want
Mar 27 11:54:37 <JaMa> for some reason "A start job is running for Run pending postinsts" takes very long time on first boot
Mar 27 11:55:16 <rburton> hm
Mar 27 11:55:30 <rburton> if you turn on debug-tweaks you'll get a log of what it's doing
Mar 27 11:55:36 <rburton> systemd?
Mar 27 11:56:29 <rburton> (by it i mean debug-tweaks will cause the postinsts to log to /var/log)
Mar 27 11:56:35 <JaMa> yes systemd-198 http://bpaste.net/show/86937/
Mar 27 11:56:52 <JaMa> probably looks different then the issue you were talking about yesterday, right?
Mar 27 11:57:20 <rburton> yes
Mar 27 11:57:27 <rburton> i wasn't getting timeouts
Mar 27 11:58:25 <rburton> your timeouts start at dev-ttyS0
Mar 27 11:58:37 <rburton> udev hanging?
Mar 27 11:58:45 <JaMa> postinsts hanging
Mar 27 11:58:52 <JaMa> everything else died already
Mar 27 11:59:08 <JaMa> debug-tweaks are enabled but nothing interesting in var/log
Mar 27 11:59:27 <rburton> hm
Mar 27 11:59:43 <JaMa> let me retest with core-image (without meta-systemd)
Mar 27 12:00:15 <rburton> postinst output should be /var/log/postinstall.log
Mar 27 12:01:05 <JaMa> nothing there
Mar 27 12:01:27 <JaMa> there is only http://bpaste.net/show/86939/
Mar 27 12:01:35 <rburton> sadface
Mar 27 12:02:05 <rburton> i ended up using netconsole and systemd.log_target=kmsg to get more useful logs out of the boot
Mar 27 12:04:21 <JaMa> rburton: btw, cover letter for v2 didn't have that nice description about possible scenarios for systemd/sysvinit
Mar 27 12:04:32 <JaMa> rburton: it would be nice to add it in local.conf.example
Mar 27 12:04:36 <rburton> JaMa: agreed
Mar 27 12:04:55 <rburton> i owe scott some material for the docs
Mar 27 12:05:16 <rburton> JaMa: are you still going to run with an overlaid systemd.bbclass in meta-systemd?
Mar 27 12:05:41 <JaMa> this image was built with that, yes
Mar 27 12:05:50 <JaMa> now I'm building core-image with only oe-core included
Mar 27 12:11:42 <otavio> pidge: now arm only but I can help with ppc with need
Mar 27 12:11:48 <otavio> pidge: what you want?
Mar 27 12:25:49 <bluelightning> otavio: who is maintaining meta-chicken? you or Mario?
Mar 27 12:25:59 <otavio> bluelightning: both
Mar 27 12:26:03 <otavio> bluelightning: :)
Mar 27 12:26:04 <rburton> meta-chicken?
Mar 27 12:26:06 <bluelightning> otavio: ok thanks
Mar 27 12:26:07 <rburton> that's a great name
Mar 27 12:26:12 <rburton> what is it? :)
Mar 27 12:26:32 <otavio> rburton: a Scheme compiler
Mar 27 12:26:36 <otavio> rburton: we use it a lot
Mar 27 12:26:52 <rburton> ah
Mar 27 12:27:49 <otavio> rburton: it can be intepreted and compiled to native code so it is great
Mar 27 12:27:58 <otavio> rburton: and is dead fast as well
Mar 27 12:28:44 <otavio> rburton: http://www.ossystems.com.br/products/software/oskiosk/ the webserver here is done using it
Mar 27 12:48:00 <JaMa> core-image build finished but qemu (not from qemu-native) fails for me with qemu: hardware error: integratorcm_read: Unimplemented offset 0x1f1018
Mar 27 12:48:12 <JaMa> sounds familiar to someone?
Mar 27 12:49:18 <rburton> JaMa: never seen that before, sorry
Mar 27 12:50:31 <JaMa> few people reported in some other places but no clear solution yet, /me googling a bit more
Mar 27 12:55:16 <JaMa> setting different -machine helps
Mar 27 12:58:55 <RP_> JaMa: I can tell you its in the machine specific code for integrator so changing machine would help...
Mar 27 12:59:02 <RP_> JaMa: we haven;t seen that problem
Mar 27 13:08:55 <hrw> RP: today is first day when I noticed how young you are ;)
Mar 27 13:22:27 <JaMa> RP_: thanks, with versatilepb it works better, now I need to find out why it does not initialize net in image at all (and later fails to mount nfs)
Mar 27 13:22:41 <JaMa> RP_: I guess runqemu works fine with qemuarm
Mar 27 13:24:37 <JaMa> ah it does not like model=virtio
Mar 27 13:33:03 <RP_> hrw: a youthful 20 ;-)
Mar 27 13:40:46 <hrw> RP_: I am nearly 045 so...
Mar 27 13:42:55 <Zagor> young is good. young people don't need so much sleep! ;-)
Mar 27 13:51:04 <Garibald1> RP_: WRT that missing 'ld' problem in my SDK we talked about yesterday, it seems I do get 'i586-poky-linux-ld.bfd'.  If I symlink 'i586-poky-linux-ld' to that file, my compilation with the SDK works.
Mar 27 13:53:11 <Garibald1> in my build directory (tmp/sysroots/x86_64-linux/usr/bin/i586-poky-linux/) I have both, but they're both hardlinked to the same file
Mar 27 13:53:48 <Garibald1> $ ls -i i586-poky-linux-ld*
Mar 27 13:53:49 <Garibald1> 8571281 i586-poky-linux-ld*  8571281 i586-poky-linux-ld.bfd*
Mar 27 13:59:10 <RP_> Garibald1: so its just the symlink that is missing?
Mar 27 13:59:49 <RP_> Garibald1: or i586-poky-linux-ld is missing too?
Mar 27 14:02:42 <Garibald1> well, i586-poky-linux-ld is missing, i586-poky-linux-ld.bfd is there
Mar 27 14:02:59 <Garibald1> when I try to compile with ${CC} I get an error about 'ld' missing
Mar 27 14:03:06 <Garibald1> ${LD} references i586-poky-linux-ld
Mar 27 14:03:18 <Garibald1> if I symlink i586-poky-linux-ld to i586-poky-linux-ld.bfd, ${CC} works
Mar 27 14:03:23 <RP_> Garibald1: locally, i586-poky-linux-ld does exist in the binutils-cross-canadian package
Mar 27 14:04:38 <RP_> Garibald1: are you using gold anywhere?
Mar 27 14:04:55 <Garibald1> gold?
Mar 27 14:05:07 <Garibald1> not explicitly in my stuff, no
Mar 27 14:05:55 <JaMa> bluelightning: I'm testing your srcrev change http://patchwork.openembedded.org/patch/46879/ os.path.remove(srcrevfile) is failing
Mar 27 14:06:07 <JaMa> bluelightning: AttributeError: 'module' object has no attribute 'remove'
Mar 27 14:06:24 <bluelightning> JaMa: er... that is not good
Mar 27 14:06:33 <RP_> Garibald1: the place to look is tmp/work/x86_64-nativesdk-pokysdk-linux/binutils-cross-canadian-i586/2.23.1-r3/
Mar 27 14:06:34 <JaMa> os.remove() is probably what you wanted
Mar 27 14:06:38 <bluelightning> gah
Mar 27 14:06:41 <RP_> Garibald1: see what got installed into image there
Mar 27 14:06:43 <bluelightning> JaMa: sorry, patch on the way
Mar 27 14:07:08 <Garibald1> RP_: it just seems odd that after sourcing environment-setup-i586-poky-linux I get a ${LD} that contains 'i586-poky-linux-ld --sysroot=/path/to/my/sysroot' when there is no i586-poky-linux-ld
Mar 27 14:07:24 <Garibald1> ok, I'll take a look
Mar 27 14:07:32 <RP_> Garibald1: it should exist , that is certain. The "ld" link never will, confirmed that now
Mar 27 14:08:03 <RP_> Garibald1: somehow, i586-poky-linux-ld is disappearing, I don't know why as its present in my build at least
Mar 27 14:08:22 <bluelightning> JaMa: actually it's not merged, will put in v2
Mar 27 14:08:38 <bluelightning> JaMa: did you have any further thoughts on the tag thing?
Mar 27 14:08:57 <Garibald1> so I have binutils-cross-canadian-i586-2.22-r17
Mar 27 14:09:04 <JaMa> not yet, I was thinking it's already included, so now I was checking "old" implementation
Mar 27 14:09:04 <Garibald1> I don't know if there's a difference
Mar 27 14:10:00 <JaMa> bluelightning: where I can read tag= from SRC_URI, but I'm thinking what will be easiest way to detect that some tags were moved
Mar 27 14:10:25 <JaMa> bluelightning: because just comparing them will show a lot of churn from changes where tag was changed correctly together with revision
Mar 27 14:10:38 <bluelightning> JaMa: hmm
Mar 27 14:10:53 <Garibald1> RP_: in /tmp/work/x86_64-nativesdk-cisco_pokysdk-linux/binutils-cross-canadian-i586-2.22-r17/p
Mar 27 14:11:15 <Garibald1> ackages-split/binutils-cross-canadian-i586/opt/cisco-poky/1.0/sysroots/x86_64-cisco_pokysdk-linux/usr/bin/i586-poky-linux I see $ ls -i i586-poky-linux-ld*
Mar 27 14:11:18 <Garibald1> 9093281 i586-poky-linux-ld*  9093281 i586-poky-linux-ld.bfd*
Mar 27 14:11:28 <Garibald1> so both are there, hardlinks to a single file
Mar 27 14:14:10 <JaMa> bluelightning: maybe it would be nice to show warning like when version is going backwards, I'll check if I can read previous srcrev info and then I could just compare tags and revs
Mar 27 14:14:55 <bluelightning> JaMa: how would we tell?
Mar 27 14:16:37 <JaMa> bluelightning: fetcher should update srcrev if BB_SRCREV_POLICY is not set to cache, so if I find the same tag but now with different revision, I can show warning
Mar 27 14:29:35 <RP_> Garibald1: so the package should have both in it and hence both should get installed :/
Mar 27 14:29:50 <RP_> Garibald1: I wonder if the hardlink is causing something a problem...
Mar 27 14:30:00 <Garibald1> yeah, I thought the same
Mar 27 14:35:00 <Garibald1> I rebuilt it last night, and I'm rerunning the sdk installer.  I'm seeign some errors that have something to do with it
Mar 27 14:35:51 <Garibald1> tar: sysroots/x86_64-cisco_pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-ld: Cannot hard link to `./opt/cisco-poky/1.0/sysroots/x86_64-cisco_pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-ld.bfd': No such file or directory
Mar 27 14:36:47 <Garibald1> odd that it's trying to do something in ./opt/cisco-poky/1.0 -- that's the default install directory and I'm not installing there
Mar 27 14:47:38 <Garibald1> RP_: this is strange.  I modified the SDK install script to write the tar file to a file and abort.  Then I extracted the tar file manually and I don't see the errors
Mar 27 14:47:55 <Garibald1> tar -jxf out.bz2 -C /tmp/b
Mar 27 14:48:32 <Garibald1> find /tmp/b -name '*-ld'
Mar 27 14:48:38 <Garibald1> /tmp/b/opt/cisco-poky/1.0/sysroots/x86_64-cisco_pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-ld
Mar 27 14:48:55 <Garibald1> so it seems to be some interplay within the installer script
Mar 27 14:49:56 <Garibald1> ah, I didn't do the --strip-components
Mar 27 14:53:22 <Garibald1> RP_: yeah, it's the --strip-components 4 in the install script.
Mar 27 14:53:45 <Garibald1> seems it's not stripping the destination of the hard link
Mar 27 14:54:25 <Garibald1> now, granted we're using gnu tar 1.15.1; maybe if we have a newer version it'd work properly.  I'll give that a shot
Mar 27 14:58:35 <RP_> Garibald1: there were some bugs in tar :/
Mar 27 15:13:13 <Garibald1> wow that's frustrating
Mar 27 15:13:24 <Garibald1> RP_: GNU tar 1.26 works
Mar 27 15:13:37 <Garibald1> I'm sorry I wasted your time
Mar 27 15:14:16 <RP_> Garibald1: its ok, we should perhaps add a check for this issue in that script
Mar 27 15:14:32 <RP_> Garibald1: could you file a bug enhancement request to that effect?
Mar 27 15:14:38 <Garibald1> sure
Mar 27 15:14:50 <Garibald1> it's the least I could do :-)
Mar 27 15:30:53 <Garibald1> RP_: I filed it - bug 4135
Mar 27 15:30:54 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4135 normal, Undecided, ---, jessica.zhang, NEW , Generated SDK installer script requires a modern version of 'tar'
Mar 27 15:31:18 <JaMa> rburton: still around?
Mar 27 15:31:22 <rburton> JaMa: aye
Mar 27 15:32:32 <JaMa> do you see some obvious mistate in http://paste.debian.net/245146/ ?
Mar 27 15:32:44 <JaMa> bitbake -e confirms that it does what it's supposed to do
Mar 27 15:34:32 <JaMa> rburton: looks like only difference after setting those is different udev provider
Mar 27 15:35:07 <JaMa> nvm, VIRTUAL-RUNTIME not VIRTUAL_RUNTIME
Mar 27 15:48:35 <zibri> rp_: have you looked at my bb.fetch2.URI class fixes? they should solve the issue we talked about at ELC with the edc.intel.com SRC_URIs, but you did mention "*multiple* test failures" (my emphasis) in your email. do you know of any other "weird" cases?
Mar 27 15:49:00 <RP_> zibri: I looked briefly and it did seem reasonable
Mar 27 15:49:13 <RP_> zibri: I haven't had time to get around to running the tests again though
Mar 27 15:49:46 <RP_> zibri: releases are falling apart and the autobuilder infrastructure has other issues so they've taken priority right now
Mar 27 15:50:47 <zibri> right, take your time :)
Mar 27 15:53:41 <JaMa> rburton: still hangs on postinsts :/ and systemd-journal is still failing with that group error
Mar 27 16:24:36 <JaMa> rburton: it finished after a while, next image (without initscripts) now boots much faster :)
Mar 27 16:27:22 <rburton> JaMa: yay
Mar 27 16:57:08 <JaMa> bluelightning: is there some reason to write SRCREV twice? Or in which cases you have different SRCREV and SRCREV_foo?
Mar 27 16:57:44 <bluelightning> JaMa: you wouldn't normally, but it's possible if that's what's written in the recipe
Mar 27 16:58:47 <bluelightning> JaMa: you certainly have cases where SRCREV_foo and SRCREV_bar are set, e.g. linux-yocto
Mar 27 16:59:04 <JaMa> bluelightning: you mean if there are multiple git repos and also SRCREV?
Mar 27 16:59:12 <bluelightning> JaMa: yes
Mar 27 16:59:18 <JaMa> bluelightning: but in such cases you shouldn't set 'SRCREV', no?
Mar 27 16:59:37 <bluelightning> JaMa: probably not no
Mar 27 17:00:00 <bluelightning> JaMa: but I'm assuming the system will use the value if a SRCREV_foo is not set
Mar 27 19:40:15 * mranostay drops pin
Mar 27 19:40:48 * zeddii hears it
Mar 27 19:43:20 * JaMa screems
Mar 27 19:45:25 * zeddii HEARS it .. and the echo
Mar 27 21:14:43 <Circuitsoft> Hello. I'm having trouble trying to write an emgd-driver-bin bitbake recipe.
Mar 27 21:15:05 <dvhart> Circuitsoft, one already exists in meta-intel
Mar 27 21:15:06 <Circuitsoft> I'm trying to install the linux driver packaged produced by the IEMGD tool with the same config as our custom video bios.
Mar 27 21:15:15 <Circuitsoft> So, I need to use emgd 1.8.
Mar 27 21:15:18 <Circuitsoft> That is the challenge.
Mar 27 21:15:34 <dvhart> If you look back in the git history, I believe we had a 1.8 in there
Mar 27 21:15:41 <Circuitsoft> So far, I've only seen 1.10.
Mar 27 21:15:45 <dvhart> ah
Mar 27 21:16:01 <Circuitsoft> And, trying to adjust the recipe to point to our file, I'm getting file-not-found errors.
Mar 27 21:16:32 <dvhart> That's typically just a path issue, where is the file and what is in your SRC_URI?
Mar 27 21:16:33 <Circuitsoft> Does this channel have a preferred pastebin?
Mar 27 21:16:36 <dvhart> nope
Mar 27 21:17:10 <Circuitsoft> http://pastebin.ca/2343677
Mar 27 21:18:09 <Circuitsoft> http://pastebin.ca/2343678 - the whole recipe
Mar 27 21:19:34 <Circuitsoft> | install: omitting directory `/home/alex/Projects/<customer>/yocto/build/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r1/IEMGD_HEAD_Linux/MeeGo1.2/usr/lib/dri'
Mar 27 21:19:55 <Circuitsoft> | install: cannot stat `/home/alex/Projects/<customer>/yocto/build/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r1/IEMGD_HEAD_Linux/MeeGo1.2/usr/lib/libEGL.so': No such file or directory
Mar 27 21:34:49 <Circuitsoft> dvhart - Any clues from the pastebin?
Mar 27 21:35:32 <dvhart> sorry Circuitsoft , pulled away on a few other topics, having a look
Mar 27 21:37:18 <dvhart> Hrm, the EGL stuff. Lots of changes there in the more recent recipes.
Mar 27 21:37:30 <dvhart> Circuitsoft, the person you want to talk to is Nitin Kamble
Mar 27 21:37:37 <dvhart> You can find him on the meta-intel list
Mar 27 21:37:53 <dvhart> He might know off the top of his head if/how he dealt with this
Mar 27 21:39:08 <dvhart> But for a sanity check, compare the path complaining it doesn't exist to a find under the emgd-driver-bin.... dir for that file
Mar 27 21:39:14 <dvhart> is there an obvious delta in the paths?
Mar 27 21:39:43 <Circuitsoft> The file does, in fact, exist at the exact path it's looking.
Mar 27 21:39:56 <Circuitsoft> I don't get those errors if I do a clean first, but then the resulting package has dangling symlinks.
Mar 27 21:41:25 <dvhart> This is all very familiar....
Mar 27 21:41:45 <dvhart> I think Nitin may know, suggest sending an email to him and meta-intel.
Mar 27 21:44:10 <Circuitsoft> The main reason we're using 1.8 is because our system bios requires a 64K VBIOS, and I wasn't able to generate one with 1.14.
Mar 27 21:44:53 <Circuitsoft> So, do I email meta-intel and just mention Nitin in the subject, or...
Mar 27 22:27:04 <dvhart> Circuitsoft, email to meta-intel, Cc Nitin and myself
Mar 27 22:49:34 <Circuitsoft> dvhart: I emailed meta-intel, but I don't have addresses for you or Nitin.
Mar 27 22:49:49 <dvhart> Circuitsoft, heh, we're not exactly hard to find
Mar 27 22:49:53 <dvhart> just look through the git log
Mar 27 22:53:28 <Circuitsoft> Ah.
Mar 27 22:54:16 * Circuitsoft got 4 hours of sleep last night, so he's a little loopy.
Mar 27 23:14:10 <ftonello> can I set a PREFERRED_PROVIDER in a recipe?
Mar 27 23:14:18 <ftonello> or just a .conf file?
Mar 28 00:31:16 <mranostay> ftonello: recipe is totally the wrong place
Mar 28 00:37:37 <ftonello> mranostay: why?
Mar 28 00:39:08 <mranostay> because recipes have PROVIDES.. you put that in a distro or machine file
Mar 28 00:42:38 <ftonello> mranostay: but I want to specify a PREFERRED_PROVIDER if I build a specific recipe, not a distro or machine
Mar 28 00:42:40 <ftonello> thats why
Mar 28 00:44:40 <mranostay> use DEPENDS?
Mar 28 00:46:51 <ftonello> mranostay: actually this PREFERRED_PROVIDER its in a .inc
Mar 28 00:47:15 <ftonello> i have 2 recipes that set this RDEPENDS_package another package
Mar 28 00:47:43 <ftonello> when its recipe a, I want to set the PREFERRED_PROVIDER for that package to be one recipe
Mar 28 00:47:56 <ftonello> when its recipe b, I want to set PREFERRED_PROVDER to another recipe
Mar 28 00:48:06 <ftonello> but I guess wont work
Mar 28 00:49:29 <ftonello> its fine, I found a better solution for this
**** ENDING LOGGING AT Thu Mar 28 02:59:58 2013