**** BEGIN LOGGING AT Tue Aug 30 02:59:57 2011 Aug 30 09:39:04 hi, i have build meta-crownbay with MACHINE="crownbay" but i'm not able to load emgd Xorg driver Aug 30 09:40:41 all the .so are present on the system, but xorg failed with drmOpenDevice: node name is /dev/dri/card0 Aug 30 09:41:04 drmopenDevice: open result is -1 (No such device) Aug 30 09:41:16 and /dev/dri/ is empty Aug 30 09:42:07 any idea ? Aug 30 10:31:30 captainigloo: not sure, but if you don't figure it out, in a few hours tomz might be around to help (he's the author of the crownbay BSP) Aug 30 10:33:43 morning all Aug 30 10:40:04 hi RP__ Aug 30 10:41:03 bluelightning: ok thanks Aug 30 11:06:59 btw i was using yocto 2.6.37 kernel, i see there is an update, so i'm building kernel 3.0.3, let see if it's better Aug 30 11:40:43 captainigloo: sounds like a good plan :) Aug 30 13:32:17 okafter testing with 3.0 linux kernel /dev/dri/card0 is present, but there is an undefined symbol in emgd_drv.so Aug 30 13:32:23 Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers/emgd_drv.so: undefined symbol: EDID_bin_read Aug 30 13:36:58 captainigloo: are you using the latest master of both poky and meta-intel? I tested everything before checking it in and didn't have a problem. And did you also get the binaries from the emgd 1.8 tarball? Aug 30 13:41:48 Guest19236: i'm using angstrom and the latest meta-intel master Aug 30 13:42:26 and for the emgd i use the 1.6 tarball, i guess Aug 30 13:42:40 i use what is written in the readme file in the meta-crownbay directory Aug 30 13:42:52 checking Aug 30 13:43:42 ah i'm using 1.6 tarball Aug 30 13:43:55 1.8 version is new ? Aug 30 13:44:39 captainigloo: yeah, 1.8 is the latest version, the version I tested with the 3.0 kernel Aug 30 13:44:52 ah non, my bad, the bb file is named 1.6 but i donwload the version 1.8 of the emgd driver Aug 30 13:46:36 Guest19236: i have the 1.8 tarball Aug 30 13:47:11 i found that : https://bugs.meego.com/show_bug.cgi?format=multiple&id=17265 Aug 30 13:47:58 and with the Option "PcfVersion" "1792" xorg is launched Aug 30 13:48:06 but nothing is displayed on screen Aug 30 13:49:56 captainigloo: anything interesting in Xorg.0.log after that? Aug 30 13:55:09 Guest19236: i see anything : http://pastebin.fr/12324 Aug 30 14:00:20 captainigloo: hmm, looks pretty normal to me, comparing to an older version - I'm going to have to build the latest version and see if I get something similar Aug 30 14:01:12 Guest19236: maybe it tries to display on the lvds interface, and not on the dvi Aug 30 14:05:37 captainigloo: hmm, maybe, could you try changing the PortOrder option to 20000 and see if that helps? Aug 30 14:05:51 captainigloo: I mean in xorg.conf Aug 30 14:12:05 I'm trying to get my head round building custom images with yocto and poky, however I can't find where poky-image-minmal is defined to start customising it.... Aug 30 14:13:56 Snafflehog: meta/recipes-core/images/poky-image-minimal.bb Aug 30 14:14:57 bluelightning: thank you Aug 30 14:29:27 Guest19236: i added Option "PortOrder" "20000" in the driver section, but same result, my monitor has no signal Aug 30 14:31:54 btw the default resolution is 960x540 which is not supported by my monitor Aug 30 14:33:30 captainigloo: so you mean in the "Device" section, I guess. Aug 30 14:33:36 i tried to set the resolution to 1024x768 with xrandr but it's not working Aug 30 14:34:02 Guest19236: yes in the Device section Aug 30 14:35:34 and there is a strange message "Inserting over stolen memory." when i launch Xorg Aug 30 14:35:58 captainigloo: one change to the same section was changing Edid to 0 - I was seeing really long delays on my lvds because of that, but I wonder if you changed it back to 1 in your case Aug 30 14:35:59 i don't like this message :) Aug 30 14:36:50 Option "Edid ""1" ? Aug 30 14:37:17 captainigloo: that message has always been there, iirc, and shouldn't be a problem Aug 30 14:37:40 captainigloo: yeah, Option "ALL/1/Port/4/General/Edid" "1" Aug 30 14:41:17 nope it doesn't work Aug 30 14:41:25 :( Aug 30 14:45:22 captainigloo: ok, well, I don't know what else to try at this point. can you file a bug in bugzilla with your system info and setup, and I'll start looking into it after reproducing it here Aug 30 14:48:45 Guest19236: file a bug in which bugzilla ? Aug 30 14:49:04 http://bugzilla.pokylinux.org/ Aug 30 14:50:35 Guest19236: even if i'm using the angrstom distro ? Aug 30 14:51:18 captainigloo: yeah, it's an emgd/meta-intel problem Aug 30 14:51:48 ok Aug 30 15:27:07 Good Morning All ! Aug 30 18:11:40 is there an ftp package in yocto? Aug 30 18:12:10 don't even seem to have wget either unless im missing something Aug 30 18:12:47 there are not very many network services in yocto Aug 30 18:13:08 what is the opinion on adding some of these recipes to meta-yocto? Aug 30 18:13:29 I'm not against it.. but there are likely a lot of them already in meta-oe... Aug 30 18:14:04 in the past we've stayed away from network services because of the security vulnerabilities they could add.. (we're not yet in a place where we can do proactive security work like we should) Aug 30 18:14:14 yes… but i dont like the idea of having to add that layer for such basic things like ftp Aug 30 18:14:37 right… the company i work for is pretty much just networking... Aug 30 18:14:50 maybe i should look to add these to our own meta layer? Aug 30 18:15:01 lots of options here... Aug 30 18:15:13 perhaps canvas opinion on the mailing list? Aug 30 18:15:48 * incandescant needs wget for some things he's playing with Aug 30 18:16:08 that makes sense Aug 30 18:16:11 thats the thing about ftp, http, etc.. for one person they're essential for another they'll never be used.. Aug 30 18:16:42 it's a trade off we made.. like I said, I'm certainly not against them being added.. but they were discussed and left out original because of other priorities.. Aug 30 18:17:53 from my perspective i want all the open source external packages for yocto in yocto itself… and all our product related foo in our own layer… Aug 30 18:18:17 Bring that up on the list... Aug 30 18:18:39 I doubt we'll end up with -everything-... but I wouldn't be surprised if additional utilities can be added... Aug 30 18:18:45 security is my biggest concern right now... Aug 30 18:18:53 fair enough Aug 30 18:19:11 i'll send an email later Aug 30 18:19:22 shortly even Aug 30 18:19:39 theother thing to remember is Yocto isn't a replacement for commercial either.. so commercial vendors are likely to step in with additional packages (and solve the security issues) Aug 30 18:19:44 so it may turn out to be a non-issue.. Aug 30 18:20:23 I think it's reasonable to expect there to be someone who looks hard at security when someone builds a commercial product atop Yocto Aug 30 18:20:39 however *some* caution wrt security is definitely a must in the open source upstream Aug 30 18:20:57 we do have someone keeping a diligent eye on vulnerability reports Aug 30 18:21:01 ya.. we're still discussing security and such in the OE TSC as well.. nothing beyond talk at this point.. Aug 30 18:21:10 but it will require a few bodies and procedures to watch and track security.. Aug 30 18:21:14 aye Aug 30 18:21:28 im not sure what we do ourselves Aug 30 18:21:29 as I said in the TSC, tracking security issues (and notification) is more important then actually fixing them -- from a priority standpoint... Aug 30 18:21:39 fray: right Aug 30 18:21:47 if we TELL people you may have a problem in XXX.. they can make a much more informed decision... Aug 30 18:21:54 * incandescant nods emphatically Aug 30 18:22:03 we've been doing that with Yocto, sorta Aug 30 18:22:15 istr at least Aug 30 18:22:15 Tom Rini and I were given the action to move forward with this when we have the time.. Aug 30 18:22:19 (from an OE stand point) Aug 30 18:22:41 fray: I'm sure we could rummage up a SIG if you care to? Aug 30 18:22:56 incandescant ya.. but we're talking about monitoring CVEs and other sources and doing this as part of our normal supprot process.. Aug 30 18:23:22 (seeing how normal support process right now is fix bugs when someone tells us.. it'll be a change.. since we'll be looking for bugs and fixing them when we tell "ourselves") Aug 30 18:23:45 Neither Tom nor I were advocating auditing or anything like that as part of this process.. simply paying attention and triaging results from standard sources Aug 30 18:24:38 fray: right, but one of our (Intel Yocto) team is already doing that - so it makes sense to open the discussion a bit, no? Aug 30 18:25:03 if only he were on IRC Aug 30 18:26:48 the discussion so far has been OE centric.. and at least in the past the expectation is Yocto would be using the OE process as well as whatever Yocto added Aug 30 18:29:11 my suggestion is that OE could, and perhaps should, use the same tools and process - or at least take inspiration from Aug 30 18:29:28 we're OE developers too ;-) Aug 30 18:29:46 a SIG makes sense at least for knowledge sharing Aug 30 18:30:08 ya.. we're just not ready yet (in OE) Aug 30 18:35:10 well, when you and Tom are ready loop in Scott Garman Aug 30 18:35:22 fray: oh, he has some public scripts and info too https://github.com/ScottGarman/YoctoSecurityAdvisoryTrackingUtility Aug 30 18:38:55 This is why I dislike github, I'd really like to have more visibility into cool things like that :/ Aug 30 18:41:14 heh Aug 30 18:41:59 on the other hand, github gets more people the tools to expose code that would otherwise not be easily viewable in public Aug 30 18:43:46 RP__: honestly, if not for github that code wouldn't be public Aug 30 18:45:05 RP__: I'm assuming visibility for you means it being on OE or Yocto infrastructure? Aug 30 18:45:31 incandescant: right Aug 30 18:45:46 incandescant: I just wish we had user repos on git.up.org... Aug 30 18:47:07 RP__, you mean mirrors there? Aug 30 18:47:45 ka6sox: no, I mean I wish that users could push general code repos onto there in a kind of user-contrib area Aug 30 18:50:06 RP__: I wish that too, it's far too hard to get any sort of repo on git.yp.org and git.oe.org which is why we have to make you suffer github :-) Aug 30 18:54:44 gitolite now supports this... Aug 30 18:54:53 * RP__ needs to find a sysadmin to enable it :) Aug 30 18:55:28 RP__, github does our sysadmin for us Aug 30 18:55:49 certainly we should have a page somewhere and encourage people to link their github stuff Aug 30 19:03:37 Crofton: gitolite does ours ;-) Aug 30 19:03:57 Turns out the server might even support this now. Can but try :) Aug 30 19:04:18 RP__, the key thing is to encourage people to use tools they are familiar with to post code Aug 30 19:04:42 Crofton: "git push" isn't familiar? Aug 30 19:04:46 github is breaking down a lot of barriers to people posting code, especially wild crazy ideas Aug 30 20:26:59 is there a way to enable/disable various QA tests? Aug 30 20:27:10 git grep QA isn't returning anything Aug 30 20:27:26 (under Documentation) Aug 30 20:34:24 dvhart: which QA tests? The insane ones or the runtime image testing ones? Aug 30 20:34:40 I think the insanse ones Aug 30 20:34:54 trying to determine why someone else gets QA failures but tom and I can't repro them Aug 30 20:35:00 dvhart: see insane.bbclass, ERROR_QA and WARN_QA Aug 30 20:35:12 re host includes and libraries Aug 30 20:35:22 looking, thanks RP Aug 30 20:35:43 * dvhart just wants to drop grub completely.... but not quite yet :) Aug 30 20:35:52 dvhart: That stuff got rewritten recently and my only comment is "better than it was" :/ Aug 30 20:36:26 noted, I shant complain too loudly Aug 30 20:36:28 ;) Aug 30 20:37:17 dvhart: its fine, I just might ask you to rewrite it or at least document it ;-) Aug 30 20:37:25 fairynuf Aug 30 20:39:05 aha Aug 30 20:39:10 and if my ERROR_QA = "" Aug 30 20:39:16 then I won't see a failure Aug 30 20:43:05 dvhart: it won't abort the build. If its in WARN_QA there should be a message in the logs Aug 30 20:43:27 right, that's what I meant. Aug 30 20:46:09 hrm, no "qa" string in log.do_configure for me though either Aug 30 20:48:02 does hob only let you select image names with prefixes of core-image? Aug 30 20:48:22 dvhart: Not every QA test currently runs through that mechanism, the do_package ones do, the do_configure one might not Aug 30 20:48:40 msm: no, it looks at what inherits image Aug 30 20:49:22 hmmm Aug 30 20:49:55 msm: incandescant knows for sure but that was the code I reviewed unless my memory is acting up Aug 30 20:50:27 i copied the file from blah to core-image-blah Aug 30 20:50:32 and it's on the drop down now Aug 30 20:50:41 but let me look closer before i say anything else Aug 30 21:16:29 msm: it should match *-image-* Aug 30 21:18:20 incandescant: that is making more sense Aug 30 21:19:16 msm: I'm open to smarter ways to detect it ;-) one may be to see if the recipe inherits a common class but I don't know if that's true for non-core images... I should probably investigate that Aug 30 21:19:21 feel free to file bugs Aug 30 21:19:36 its fine, i didnt really think about it… i just wondered why mine was not there Aug 30 21:19:44 and upon renaming it was =) Aug 30 21:19:50 fair enough Aug 30 22:40:37 does the LSB speci include X11? Aug 30 22:40:54 yes Aug 30 22:41:10 there is no LSB sans X11? Aug 30 22:41:21 well Aug 30 22:41:34 The LSB spec requires X11.. Aug 30 22:41:38 ok Aug 30 22:41:39 you can build with an LSB like system w/o X11 Aug 30 22:42:00 right, is there anything like that I should look at before giving it a shot on my own Aug 30 22:42:41 you will need to build your own image/task for a system w/o X11 (LSB that is) Aug 30 22:42:56 look at the task-core-lsb and core-image-lsb for details on how the current LSB is constructed Aug 30 22:43:11 right, including just task-core-lsb pulls in all of X11 Aug 30 22:43:17 but thats fine, i'll investigate more Aug 30 22:43:23 The LSB image is really a test image, we don't think anyone will really use it Aug 30 22:43:36 look at task-core-lsb.. each chunk is broken down, just don't include the graphics bit Aug 30 22:43:49 task-core-lsb-graphic-add \ Aug 30 22:44:02 well the LSB might get more action on our products Aug 30 22:44:28 particularly like lsb-sdk w/ everything included Aug 30 22:44:34 its good for evaluating our parts Aug 30 22:44:39 LSB is nice from the standpoint of ABI compatibility.. but it's not really going to be good for end devices.. Aug 30 22:44:49 then stepping down to something similiar to core-image-minimal for actual deployment Aug 30 22:44:49 yes, evaluation it should be fine.. and frankly it's a checkbox item people ask for Aug 30 22:44:53 but nobody uses Aug 30 22:45:29 we include hard drives and sd cards with our development systems Aug 30 22:45:59 seems like the image to use when space is not an issue Aug 30 22:46:04 ya even so.. nobody I know uses LSB in a deployed (embedded) product Aug 30 22:46:34 the problem w/ an LSB image is that it assumes you can just have stuff you aren't using hanging around on teh system... I know of no production embedded systems that are like that Aug 30 22:46:38 everything on there has a purpose Aug 30 22:46:45 right Aug 30 22:46:52 our parts borderline embedded too though Aug 30 22:46:55 but for development it makes sense Aug 30 22:47:08 right **** ENDING LOGGING AT Wed Aug 31 02:59:57 2011