**** BEGIN LOGGING AT Wed Mar 27 02:59:58 2013 Mar 27 08:19:03 good morning Mar 27 08:28:48 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 morning all Mar 27 11:13:27 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 oh, nevermind.. It was well explained in packagegroup-core-boot Mar 27 11:52:19 erbo: VIRTUAL_RUNTIME_init-manager, after adding the systemd distro feature if that's what you want Mar 27 11:54:37 for some reason "A start job is running for Run pending postinsts" takes very long time on first boot Mar 27 11:55:16 hm Mar 27 11:55:30 if you turn on debug-tweaks you'll get a log of what it's doing Mar 27 11:55:36 systemd? Mar 27 11:56:29 (by it i mean debug-tweaks will cause the postinsts to log to /var/log) Mar 27 11:56:35 yes systemd-198 http://bpaste.net/show/86937/ Mar 27 11:56:52 probably looks different then the issue you were talking about yesterday, right? Mar 27 11:57:20 yes Mar 27 11:57:27 i wasn't getting timeouts Mar 27 11:58:25 your timeouts start at dev-ttyS0 Mar 27 11:58:37 udev hanging? Mar 27 11:58:45 postinsts hanging Mar 27 11:58:52 everything else died already Mar 27 11:59:08 debug-tweaks are enabled but nothing interesting in var/log Mar 27 11:59:27 hm Mar 27 11:59:43 let me retest with core-image (without meta-systemd) Mar 27 12:00:15 postinst output should be /var/log/postinstall.log Mar 27 12:01:05 nothing there Mar 27 12:01:27 there is only http://bpaste.net/show/86939/ Mar 27 12:01:35 sadface Mar 27 12:02:05 i ended up using netconsole and systemd.log_target=kmsg to get more useful logs out of the boot Mar 27 12:04:21 rburton: btw, cover letter for v2 didn't have that nice description about possible scenarios for systemd/sysvinit Mar 27 12:04:32 rburton: it would be nice to add it in local.conf.example Mar 27 12:04:36 JaMa: agreed Mar 27 12:04:55 i owe scott some material for the docs Mar 27 12:05:16 JaMa: are you still going to run with an overlaid systemd.bbclass in meta-systemd? Mar 27 12:05:41 this image was built with that, yes Mar 27 12:05:50 now I'm building core-image with only oe-core included Mar 27 12:11:42 pidge: now arm only but I can help with ppc with need Mar 27 12:11:48 pidge: what you want? Mar 27 12:25:49 otavio: who is maintaining meta-chicken? you or Mario? Mar 27 12:25:59 bluelightning: both Mar 27 12:26:03 bluelightning: :) Mar 27 12:26:04 meta-chicken? Mar 27 12:26:06 otavio: ok thanks Mar 27 12:26:07 that's a great name Mar 27 12:26:12 what is it? :) Mar 27 12:26:32 rburton: a Scheme compiler Mar 27 12:26:36 rburton: we use it a lot Mar 27 12:26:52 ah Mar 27 12:27:49 rburton: it can be intepreted and compiled to native code so it is great Mar 27 12:27:58 rburton: and is dead fast as well Mar 27 12:28:44 rburton: http://www.ossystems.com.br/products/software/oskiosk/ the webserver here is done using it Mar 27 12:48:00 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 sounds familiar to someone? Mar 27 12:49:18 JaMa: never seen that before, sorry Mar 27 12:50:31 few people reported in some other places but no clear solution yet, /me googling a bit more Mar 27 12:55:16 setting different -machine helps Mar 27 12:58:55 JaMa: I can tell you its in the machine specific code for integrator so changing machine would help... Mar 27 12:59:02 JaMa: we haven;t seen that problem Mar 27 13:08:55 RP: today is first day when I noticed how young you are ;) Mar 27 13:22:27 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 RP_: I guess runqemu works fine with qemuarm Mar 27 13:24:37 ah it does not like model=virtio Mar 27 13:33:03 hrw: a youthful 20 ;-) Mar 27 13:40:46 RP_: I am nearly 045 so... Mar 27 13:42:55 young is good. young people don't need so much sleep! ;-) Mar 27 13:51:04 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 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 $ ls -i i586-poky-linux-ld* Mar 27 13:53:49 8571281 i586-poky-linux-ld* 8571281 i586-poky-linux-ld.bfd* Mar 27 13:59:10 Garibald1: so its just the symlink that is missing? Mar 27 13:59:49 Garibald1: or i586-poky-linux-ld is missing too? Mar 27 14:02:42 well, i586-poky-linux-ld is missing, i586-poky-linux-ld.bfd is there Mar 27 14:02:59 when I try to compile with ${CC} I get an error about 'ld' missing Mar 27 14:03:06 ${LD} references i586-poky-linux-ld Mar 27 14:03:18 if I symlink i586-poky-linux-ld to i586-poky-linux-ld.bfd, ${CC} works Mar 27 14:03:23 Garibald1: locally, i586-poky-linux-ld does exist in the binutils-cross-canadian package Mar 27 14:04:38 Garibald1: are you using gold anywhere? Mar 27 14:04:55 gold? Mar 27 14:05:07 not explicitly in my stuff, no Mar 27 14:05:55 bluelightning: I'm testing your srcrev change http://patchwork.openembedded.org/patch/46879/ os.path.remove(srcrevfile) is failing Mar 27 14:06:07 bluelightning: AttributeError: 'module' object has no attribute 'remove' Mar 27 14:06:24 JaMa: er... that is not good Mar 27 14:06:33 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 os.remove() is probably what you wanted Mar 27 14:06:38 gah Mar 27 14:06:41 Garibald1: see what got installed into image there Mar 27 14:06:43 JaMa: sorry, patch on the way Mar 27 14:07:08 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 ok, I'll take a look Mar 27 14:07:32 Garibald1: it should exist , that is certain. The "ld" link never will, confirmed that now Mar 27 14:08:03 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 JaMa: actually it's not merged, will put in v2 Mar 27 14:08:38 JaMa: did you have any further thoughts on the tag thing? Mar 27 14:08:57 so I have binutils-cross-canadian-i586-2.22-r17 Mar 27 14:09:04 not yet, I was thinking it's already included, so now I was checking "old" implementation Mar 27 14:09:04 I don't know if there's a difference Mar 27 14:10:00 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 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 JaMa: hmm Mar 27 14:10:53 RP_: in /tmp/work/x86_64-nativesdk-cisco_pokysdk-linux/binutils-cross-canadian-i586-2.22-r17/p Mar 27 14:11:15 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 9093281 i586-poky-linux-ld* 9093281 i586-poky-linux-ld.bfd* Mar 27 14:11:28 so both are there, hardlinks to a single file Mar 27 14:14:10 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 JaMa: how would we tell? Mar 27 14:16:37 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 Garibald1: so the package should have both in it and hence both should get installed :/ Mar 27 14:29:50 Garibald1: I wonder if the hardlink is causing something a problem... Mar 27 14:30:00 yeah, I thought the same Mar 27 14:35:00 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 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 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 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 tar -jxf out.bz2 -C /tmp/b Mar 27 14:48:32 find /tmp/b -name '*-ld' Mar 27 14:48:38 /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 so it seems to be some interplay within the installer script Mar 27 14:49:56 ah, I didn't do the --strip-components Mar 27 14:53:22 RP_: yeah, it's the --strip-components 4 in the install script. Mar 27 14:53:45 seems it's not stripping the destination of the hard link Mar 27 14:54:25 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 Garibald1: there were some bugs in tar :/ Mar 27 15:13:13 wow that's frustrating Mar 27 15:13:24 RP_: GNU tar 1.26 works Mar 27 15:13:37 I'm sorry I wasted your time Mar 27 15:14:16 Garibald1: its ok, we should perhaps add a check for this issue in that script Mar 27 15:14:32 Garibald1: could you file a bug enhancement request to that effect? Mar 27 15:14:38 sure Mar 27 15:14:50 it's the least I could do :-) Mar 27 15:30:53 RP_: I filed it - bug 4135 Mar 27 15:30:54 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 rburton: still around? Mar 27 15:31:22 JaMa: aye Mar 27 15:32:32 do you see some obvious mistate in http://paste.debian.net/245146/ ? Mar 27 15:32:44 bitbake -e confirms that it does what it's supposed to do Mar 27 15:34:32 rburton: looks like only difference after setting those is different udev provider Mar 27 15:35:07 nvm, VIRTUAL-RUNTIME not VIRTUAL_RUNTIME Mar 27 15:48:35 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 zibri: I looked briefly and it did seem reasonable Mar 27 15:49:13 zibri: I haven't had time to get around to running the tests again though Mar 27 15:49:46 zibri: releases are falling apart and the autobuilder infrastructure has other issues so they've taken priority right now Mar 27 15:50:47 right, take your time :) Mar 27 15:53:41 rburton: still hangs on postinsts :/ and systemd-journal is still failing with that group error Mar 27 16:24:36 rburton: it finished after a while, next image (without initscripts) now boots much faster :) Mar 27 16:27:22 JaMa: yay Mar 27 16:57:08 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 JaMa: you wouldn't normally, but it's possible if that's what's written in the recipe Mar 27 16:58:47 JaMa: you certainly have cases where SRCREV_foo and SRCREV_bar are set, e.g. linux-yocto Mar 27 16:59:04 bluelightning: you mean if there are multiple git repos and also SRCREV? Mar 27 16:59:12 JaMa: yes Mar 27 16:59:18 bluelightning: but in such cases you shouldn't set 'SRCREV', no? Mar 27 16:59:37 JaMa: probably not no Mar 27 17:00:00 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 Hello. I'm having trouble trying to write an emgd-driver-bin bitbake recipe. Mar 27 21:15:05 Circuitsoft, one already exists in meta-intel Mar 27 21:15:06 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 So, I need to use emgd 1.8. Mar 27 21:15:18 That is the challenge. Mar 27 21:15:34 If you look back in the git history, I believe we had a 1.8 in there Mar 27 21:15:41 So far, I've only seen 1.10. Mar 27 21:15:45 ah Mar 27 21:16:01 And, trying to adjust the recipe to point to our file, I'm getting file-not-found errors. Mar 27 21:16:32 That's typically just a path issue, where is the file and what is in your SRC_URI? Mar 27 21:16:33 Does this channel have a preferred pastebin? Mar 27 21:16:36 nope Mar 27 21:17:10 http://pastebin.ca/2343677 Mar 27 21:18:09 http://pastebin.ca/2343678 - the whole recipe Mar 27 21:19:34 | install: omitting directory `/home/alex/Projects//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 | install: cannot stat `/home/alex/Projects//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 dvhart - Any clues from the pastebin? Mar 27 21:35:32 sorry Circuitsoft , pulled away on a few other topics, having a look Mar 27 21:37:18 Hrm, the EGL stuff. Lots of changes there in the more recent recipes. Mar 27 21:37:30 Circuitsoft, the person you want to talk to is Nitin Kamble Mar 27 21:37:37 You can find him on the meta-intel list Mar 27 21:37:53 He might know off the top of his head if/how he dealt with this Mar 27 21:39:08 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 is there an obvious delta in the paths? Mar 27 21:39:43 The file does, in fact, exist at the exact path it's looking. Mar 27 21:39:56 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 This is all very familiar.... Mar 27 21:41:45 I think Nitin may know, suggest sending an email to him and meta-intel. Mar 27 21:44:10 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 So, do I email meta-intel and just mention Nitin in the subject, or... Mar 27 22:27:04 Circuitsoft, email to meta-intel, Cc Nitin and myself Mar 27 22:49:34 dvhart: I emailed meta-intel, but I don't have addresses for you or Nitin. Mar 27 22:49:49 Circuitsoft, heh, we're not exactly hard to find Mar 27 22:49:53 just look through the git log Mar 27 22:53:28 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 can I set a PREFERRED_PROVIDER in a recipe? Mar 27 23:14:18 or just a .conf file? Mar 28 00:31:16 ftonello: recipe is totally the wrong place Mar 28 00:37:37 mranostay: why? Mar 28 00:39:08 because recipes have PROVIDES.. you put that in a distro or machine file Mar 28 00:42:38 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 thats why Mar 28 00:44:40 use DEPENDS? Mar 28 00:46:51 mranostay: actually this PREFERRED_PROVIDER its in a .inc Mar 28 00:47:15 i have 2 recipes that set this RDEPENDS_package another package Mar 28 00:47:43 when its recipe a, I want to set the PREFERRED_PROVIDER for that package to be one recipe Mar 28 00:47:56 when its recipe b, I want to set PREFERRED_PROVDER to another recipe Mar 28 00:48:06 but I guess wont work Mar 28 00:49:29 its fine, I found a better solution for this **** ENDING LOGGING AT Thu Mar 28 02:59:58 2013