**** BEGIN LOGGING AT Thu Apr 04 02:59:58 2013 Apr 04 07:00:32 bluelightning: reply to icecc was intentionally off-list or can I reply to list with link to wiki? Apr 04 07:02:15 JaMa: intentionally... I figured not everyone needed to see me grumbling :) Apr 04 07:03:07 replying on list to your post with the link might be useful anyway though Apr 04 07:03:15 ok :) Apr 04 07:38:50 JaMa: I guess you have been using icecc then? Apr 04 07:40:22 not really, some guys in office are using that and asked me for help, I've tested it locally, but because I work remotely it's faster to build here then use icecc over slow VPN Apr 04 07:43:20 ok... I was just wondering what kind of performance you were seeing if you were using it Apr 04 15:31:05 bluelightning, did you develop the new metadata index site? Apr 04 15:32:50 zenlinux: I did, with design help from belen and review/bugfixes from halstead & adam_ian Apr 04 15:33:05 wow, really nice job all of you Apr 04 15:33:12 thanks! Apr 04 15:33:16 we've totally needed this Apr 04 15:58:10 hrw: around? want to talk about the elfutils issue? Apr 04 15:58:34 sgw_: just planned to leave but can stay for few more minutes Apr 04 15:59:07 hrw: sorry to catch you like that Apr 04 15:59:24 sgw_: timezone difference Apr 04 16:00:12 hrw: I just did a clean build and it worked correctly, not bitbake fails, I wonder what other layers or distro settings, are you doing poky or oe-core? Apr 04 16:00:43 sgw_: oe-core + meta-oe + meta-linaro + meta-linaro-toolchain + meta-aarch64 Apr 04 16:01:02 few other layers included as well but only as source of possible failures Apr 04 16:01:46 Ok, I will try an oe-core + meta-oe Apr 04 16:02:00 removed all not needed ones and retried Apr 04 16:02:08 I know that a poky build worked Apr 04 16:02:21 http://pastebin.com/CarqG70A - conf/bblayers.conf Apr 04 16:06:15 sgw_: the real fun is that I may not need that split anymore... but probably others may like it Apr 04 16:06:15 hrw: sorry, I will try again and let you know by email, might be something in your layer set. Apr 04 16:06:22 ok Apr 04 16:06:49 does order matters? Apr 04 16:06:56 enjoy your evening, thanks for staying Apr 04 16:07:02 hrw: not sure Apr 04 16:09:48 reeordered so its now: oe-core, meta-oe, meta-linaro and rest - gcc related entries started to rebuild Apr 04 16:10:13 probably order matters Apr 04 16:10:21 have a nice day Saul Apr 04 16:10:23 * hrw -> off Apr 04 16:10:28 hrw: you also Apr 04 18:28:55 sgw_: fixed layers order and got that bug Apr 04 18:29:02 sgw_: I meant QA errors Apr 04 18:32:33 INSANE_SKIP_libdw = "dev-so" Apr 04 18:32:46 this is in recipe and takes care of QA errors for normal builds Apr 04 18:32:49 INSANE_SKIP_lib32-libdw = "dev-so" Apr 04 18:33:02 was needed for this multilib one but it is not proper solution Apr 04 18:33:25 isn't the insane_skip (for multilibs) renamed automatically? if not, it should be.. Apr 04 18:34:02 What the hell, this is weird. I added two Terminal classes to oe.terminal, but only one is showing up in the list Apr 04 18:34:06 * kergoth scratches head Apr 04 18:34:09 I believe you can do "${MLPREFIX}libdw" as well Apr 04 18:35:09 ugly Apr 04 18:35:15 checking Apr 04 18:36:38 built fine Apr 04 18:42:05 hrw: that makes sense, I think the repacking is reasonable, but if you are ok for now, maybe this can wait for 1.5 Apr 04 18:43:01 sgw_: for me this can wait Apr 04 18:43:16 Ok, if you want to send a v2 now, I will queue for 1.5 Apr 04 18:43:31 v4 I think it will be ;d Apr 04 18:49:05 ok. builds also for normal builds Apr 04 19:08:02 i really wish the bot in here didnt notie the whole channel Apr 04 19:08:05 notice* Apr 04 19:13:19 Daemon404, I'll see if I can help with that. Apr 04 19:13:49 i could just put it on ignore Apr 04 19:13:51 that also works Apr 04 23:59:57 kergoth: Were you trying to add the tmux or something else to the terminal class? Apr 05 00:00:22 I was contemplating adding tmux support in the same way screen was added where it can auto attach. Apr 05 00:00:42 that's what it does, yes. did you not read the email? Apr 05 00:01:21 it adds two classes, one is high priority and opens a new pane in the existing current tmux window, for when you're running bitbake inside of a tmux session, the other is lower priority (though higher than screen), and spawns a new session and uses the same mechanism as screen does Apr 05 00:01:36 I just saw your irc comment. Apr 05 00:02:00 oh :) there's an email on the oe-core list with the patch :) Apr 05 00:02:04 I didn't know you had created some patches :-) Apr 05 00:02:30 hehe Apr 05 00:02:35 I just assumed you might be working on it because I was going to enter a buzilla req 2 weeks ago and so you already had it in there. Apr 05 00:02:42 do try it out, let me know if it works for you Apr 05 00:02:43 * kergoth nods Apr 05 00:08:25 ERROR: OE_TERMINAL: Invalid choice 'tmux'. Valid choices: auto none custom tmux-running gnome konsole xfce rxvt xterm screen Apr 05 00:11:09 I guess it is tmuxnewssion, my bad. Apr 05 00:12:30 kergoth: It works fine after using the right OE_TERMINAL var. Apr 05 00:13:25 * jwessel wonders what the difference is between "tmux-running tmuxrunning" Apr 05 00:22:57 Hmm, that's odd Apr 05 00:23:02 * kergoth investigates Apr 05 00:23:27 I was just going to type up a mail to your patch, but before doing so I wanted to test something. Apr 05 00:23:41 This looks like it will fall victim to the same thing the original screen stuff did. Apr 05 00:24:15 Where if two builds are running the tmux needs to be associated by pid for the "newsession" variant. Apr 05 00:24:56 Hmm, I swear I already made it use the pid, damn, I really mixed up this patch Apr 05 00:25:05 No worries. Apr 05 00:25:05 I'll send a v3 taking those issues into account, thanks for the feedback Apr 05 00:25:36 The other thing that had me scratching my head was the "tmuxrunning". Apr 05 00:26:04 If I didn't have a tmux already running, it wouldn't spawn a new one e.g. OE_TERMINAL=tmuxrunning bitbake -c devshell busybox Apr 05 00:26:17 It just failed through and spanwed gnome terminal instead. Apr 05 00:27:01 Hmmmm Apr 05 00:27:02 For ease of use you might consider just calling the other class invocation on failure of the tmuxrunning. Apr 05 00:27:33 Yeah, it's something to think about. I never actually used tmuxrunning manually, since its higher priority than theo ther terminals, you can just use 'auto' and if you're under tmux, it'll open a split Apr 05 00:27:34 What you have there works fine if you don't have a DISPLAY variable set. Apr 05 00:27:39 * kergoth nods Apr 05 00:28:24 yup. I totally see what you are going for, and I never would have even thought to use tmux that way. Apr 05 00:29:31 I tend to associate one task to one build, and not think about it from a multiplexing capacity like you added. Seems interesting, but my preference would be to just serially use it similar to the screen integration, but that is purely a personal preference. Apr 05 00:30:19 not sure what you mean by multiplexing. it's not any different than the screen one,e xcept it can open in the current tmux window if you're already in one, rather than opening a new window or session Apr 05 00:30:33 I won't bother send the mail to the list since we chatted here. I'll probably try the next iteration too. Apr 05 00:31:01 * kergoth nods Apr 05 00:31:12 I'll give it some more thought and send out another one Apr 05 00:31:14 thanks again Apr 05 00:31:18 That is what I mean by multiplexing. It will spawn in what ever session you already have running. Apr 05 00:31:31 Thanks for implementing it. Tmux is quite useful. Apr 05 00:32:14 I was even thinking of going a step further and adding it as a -native tool. Apr 05 00:32:42 That way we can always fall back on it on what ever development host I am on, as we tend to support lots and lots of hosts. Apr 05 00:33:17 That's an interesting idea. it'd make sure that the devshell is always useful even on headless minimalist servers Apr 05 00:34:24 Correct. That is primary problem we face today from the commercial side. Apr 05 00:34:36 We addressed it by forcing the install of screen as a required tool. Apr 05 00:34:45 But eventually screen will be phased out of newer distros. Apr 05 00:35:01 So the days of screen are getting numbered with it being long in the tooth. Apr 05 00:35:58 I wasn't sure to what extent you requirement to implement tmux, but I was thinking of it from the "make the default console interface" perspective. Apr 05 00:50:37 halstead: ping. did something happen to ab06? Apr 05 01:46:19 I'm using BBCLASSEXTEND and variants (like multilib) to build some out-of-tree modules against multiple kernel trees. This makes having userland recipes (R)DEPENDS on a kernel recipe (e.g., for an ioctl header) difficult unless I BBCLASSEXTENDS them the same way--but the variants don't actually differ; they just build the same bits over and over.... Is there any way to say "these two recipes are aliases of each other"? **** ENDING LOGGING AT Fri Apr 05 02:59:58 2013