**** BEGIN LOGGING AT Tue May 27 02:59:58 2014 May 27 06:56:32 good morning May 27 08:06:41 I tried following http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#using-systemd-exclusively for my image, but it seemed to have no effect. May 27 08:58:55 morning all May 27 09:05:38 hi bluelightning May 27 09:19:53 morning mckoan May 27 10:05:19 <_valle_> I'm having trouble getting the wlan module to load. I pasted some information from my system: http://pastebin.com/cXzBGrC1 May 27 10:11:30 <_valle_> What am I missing? There is no device in /sys/class/net May 27 10:18:09 _valle_: are you sure you enabled the wifi device in your kernel? May 27 10:18:42 anyone know how to manually update the *Packages* file, to re-generate the packages list .. May 27 10:19:27 dlan: bitbake package-index May 27 10:22:11 rburton: thanks May 27 10:23:12 actually I tried "bitbake --help ", but doesn't find that command .. May 27 10:25:50 —help doesn't list targets May 27 10:26:03 and package-index is a build target, like core-image-sato or eglibc May 27 10:26:13 em... doesn't works for me, run "grep" give nothing. http://bpaste.net/show/305580/ May 27 10:26:33 I'm using opkg here, should that also works? May 27 10:26:53 dlan: try the Packages file in mips32el May 27 10:27:18 oh, possible that reason May 27 10:37:19 I'm facing this error: error: file /usr/lib/libEGL.so.1.0.0 conflicts between attempted installs of .armv7a_vfp_neon and libegl-mesa-9.1.6-r0.armv7a_vfp_neon May 27 10:38:44 i'm using PREFERRED_PROVIDER_virtual/egl and _virtual/glesv2 = in local.conf May 27 10:39:37 Smart: virtual/libgles2 May 27 10:40:03 see PROVIDES in mesa.inc for the names that you'll want to re-assign if you don't want mesa turning up May 27 10:41:40 rburton : sorry for the typo...i'm indeed using virtual/libgles2. I also tried commenting virtual/libgles2 & virtual/egl from PROVIDES of mesa.inc but it still gives the same error. May 27 10:42:33 if i add PROVIDES=virtual/libgles2 virtual/egl in my_lib.bb then it throws some other error. May 27 10:43:21 Smart: you need those provides, and you'll want to set the other virtual provider names too otherwise mesa can still be built May 27 10:44:01 Smart: are you writing a BSP, or using an existing one? May 27 10:44:47 yes m creating my own bsp layer with custom kernel. which builds successfully. May 27 10:45:05 now i'm playing with multimedia and graphics recipes. May 27 10:46:05 so i can't have a set-up where mesa.inc provides libs other than libEGL and libGLESV2. which i want my_lib to take care of ? May 27 10:48:12 <_valle_> mckoan: How do I check this? May 27 10:48:55 Smart: you want mesa-gl May 27 10:49:05 Smart: well, two options May 27 10:49:12 Smart: the question is do you *need* GLX May 27 10:49:57 how could I enable *v4l* feature in gstreamer/gst-plugins-good_0.10.31.bb, seems there is "PACKAGECONFIG[v4l]" in that file May 27 10:50:41 _valle_: look at the boot log, the .config of your kernel May 27 10:53:21 rburton : yes i need GLX. by that i mean the libGL* libs from my_lib so that i can test basic *gl* app. May 27 10:53:51 Smart: but your drivers don't do GLX? May 27 10:54:08 oh sorry, misread May 27 10:54:39 if your drivers provide libGL then just set virtual/libgl to your library too May 27 10:55:08 if you're swapping GL driver you need to provide a name for each of PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl virtual/mesa" May 27 10:55:31 which are libGL, libGLESv1, libGLESv2 libEGL and the mesa-specific interfaces, respectively May 27 10:55:48 if your GL doesn't pretend to be mesa, then set the virtual/mesa preferred provider to "" May 27 10:56:41 some hardware only does EGL and GLESv2 which is why there's a mesa-gl recipe that will build a software-only libGL for people who want GL to work, even if its pure software May 27 11:01:01 dlan: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGECONFIG May 27 11:01:13 dlan: see the end of the PACKAGECONFIG entry there May 27 11:02:00 rburton: have you experience with vivante/etna ? May 27 11:02:39 ant_work: nope May 27 11:02:46 ant_work: I would have thought that would be more up otavio's street... May 27 11:02:55 <_valle_> mckoan: The parts containing wifi in the .config are the one from this pastebin: http://pastebin.com/cXzBGrC1. Do I need to have something more in the kernel? May 27 11:03:12 I'm a bit scared after reading the last comment about mesa-gl May 27 11:03:26 <_valle_> mckoan: Its in the end of the pastebin May 27 11:04:16 ant_work: if the hardware doesn't have GL support but you need GLX, then it's all you can do May 27 11:04:22 ant_work: on linux, GL == GLX May 27 11:04:55 bluelightning: thanks May 27 11:09:29 rburton: seems it is OPENGL ES 2.0 May 27 11:09:47 and there is a gallium driver May 27 11:10:39 ant_work: fwiw the closed-driver intel platforms that use EMGD use mesa-gl and drop in a hardware driver that mesa uses May 27 11:12:45 rburton : thanks. I'll check on it. one last question - can't i have "virtual/libgles1 virtual/libgles2 virtual/egl" from my package and "virtual/libgl virtual/mesa" from mesa.inc ? May 27 11:14:33 Smart: almost certainly not May 27 11:14:47 just set it to "" if you don't have a GL driver that has mesa API (specifically gbm, wayland) May 27 11:26:44 rburton : thanks. will certainly try it. but out of curiosity may i know why we can't do that. >>almost certainly not May 27 11:27:30 Smart: because the bits of mesa you need for eg weston are not standalone libraries but integrated with the rest of mesa May 27 11:32:43 rburton : okay. probably i'll need a bit of reading on this. anyways thanks a lot for the help. will get back if any problem. May 27 12:21:58 _valle_: no that is not enough. pastebin the whoòe .config and the boot log May 27 12:22:08 s/whoòe/whole May 27 12:22:32 _valle_: and details about your board May 27 12:36:06 hi. May 27 12:36:07 how can i build static libc with poky ? May 27 12:36:14 <_valle_> mckoan: I checked out an ltib build. The ltib build had the packages csr-linux-wifi and wpa_supplicant_csr. May 27 12:36:44 <_valle_> mckoan: How could I get these packages with yocto? May 27 12:37:41 _valle_: before all I'd suggest you to check if your wifi component in activated May 27 12:46:20 <_valle_> mckoan: Its always active when powered May 27 14:59:12 YPTM: Participant passcode: 42001078 Dial-in number: 1.972.995.7777 US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.7777x42001078# May 27 14:59:34 YPTM: Stephen Joined May 27 14:59:49 YPTM: Jeff Polk joined May 27 14:59:59 YPTM: Armin joined May 27 15:00:16 Saul is on May 27 15:00:19 YPTM: Scott Rifenbark joined the call. May 27 15:00:29 YPTM: Sean Hudson joined May 27 15:00:33 YPTM: Tom Z on the call May 27 15:00:48 YPTM: Paul Eggleton is on May 27 15:01:28 YPTM: belen joined May 27 15:01:32 YPTM: Matthew joined May 27 15:01:34 YPTM: Bruce Ashfield on the call. May 27 15:01:51 YPTM: Richard joined May 27 15:02:07 I'm having some trouble connecting. Did the passcode change from 42001078? May 27 15:02:26 halstead: nope May 27 15:02:28 halstead: nope same code May 27 15:02:29 YPTM: ross joined May 27 15:03:23 YPTM: Michael on now. May 27 15:04:23 sounds like someone is doing dishes :) May 27 15:04:59 alex d online May 27 15:06:03 * nitink is on YPTM call May 27 15:06:49 RP: what was that last bit? May 27 15:06:55 * LCyrin shows up in the call May 27 15:07:05 darknighte_: python devshell May 27 15:08:16 excellent. I think I heard you say that you just posted an updated patch set with command history. May 27 15:08:19 anything else? May 27 15:11:17 sgw_: what time US-PDT? May 27 15:12:29 darknighte_: command history and things like exit() and Ctrl C/D working correctly May 27 15:12:42 darknighte_: I just posted the updated patch May 27 15:12:48 RP: thx. I'll take a look. May 27 15:13:51 is it mesa Ross is talking about? May 27 15:13:56 sjolley: mes May 27 15:14:00 yes May 27 15:18:09 darknighte_: thanks for looking at mesa on amd. in theory their drivers are open and upstreamed so mesa10 is a trivial move, right? ;) May 27 15:18:58 YPTM is over! May 27 15:19:10 rburton: indeed. in fact, it looks like we are tracking MESA 10 already, at least for one platform. May 27 15:19:51 * darknighte_ notices his ml backlog is now measured in 100's and sighs May 27 15:21:41 rburton: not sure if this is of interest: http://upstream-tracker.org/compat_reports/mesa/9.2.4_to_10.0.2/abi_compat_report.html#Low_Risk_Problems May 27 15:22:26 although I guess you did say it was more runtime that was a concern May 27 15:23:15 i keep on forgetting about that web site May 27 15:24:07 bluelightning: the external API should have just grown, it's the drivers. EMGD drops a DRM driver in but the DRM interface isn't stable and can change. I think a freescale board does the same. May 27 15:50:02 is ifplugd part of some other recipe (e.g. ethtools) or does that recipe no longer exist (ifplugd)? May 27 15:51:46 or, has ifplugd been deprecated in favor of connman? May 27 15:52:00 T0mW: I don't know. In our product we have a bbappend for busybox to use the busybox ifplugd May 27 15:57:33 T0mW: the full ifplugd isn't really maintained upstream; there was a patch sent to add a recipe for it but given its abandoned status I'm not sure maintaining that is the best idea May 27 15:58:06 probably either connman or as zecke suggests busybox's ifplugd would be the options to look at May 27 16:01:10 bluelightning: I try to stay away from busybox for most of my stuff. It is good for a constrained resource system, but, many utils have unique syntax or reduced functionality. The busybox ifplugd does not work. I take a good look at connman. May 27 16:01:19 bluelightning, zecke : thanks May 27 16:09:57 rburton: RP: on the MESA version, I have not hard reason to preserve MESA 9 at this point. May 27 16:10:36 darknighte_: awesome, thanks May 27 16:11:22 despite that, I still lean towards keeping the older version around for a little while. May 27 16:11:37 it's a matter of preference though. May 27 16:11:54 I'll respond to the patch on the list to see if it stirs up any other comments May 27 16:18:11 rburton: ^ May 27 16:18:23 thanks :) May 27 16:51:23 zeddii: you have a feeling for what the kernel versions are going to be for the next release? May 27 16:55:07 tomz2: ^ same question for you May 27 17:14:01 dang! the tether to the android phone (Samsung GS3) is using IPV6! May 27 17:17:01 darknighte_, 3.14 + ~3.16 May 27 17:17:31 3.14 *should* be the new LTSI, and 3.16 the latest we can grab. May 27 17:21:08 zeddii: thx. I saw that Greg KH pulled the patches forward to 3.14 for LTSI, but wanted to double check. May 27 17:21:34 any feeling for the next LTS? ~3.16 too ? May 27 17:23:13 zeddii: ^ May 27 17:30:11 greg would likely just do the normal treatment for that, I'd expect he'll maintain it until 3.17 and only if someone else step up will it go longer. May 27 17:30:23 otherwise, I'll toss it in the bin for the 2015 release. May 27 18:28:42 * kroon wonders why lots of files changed perm from 644 to 664 and 666 in the latest build from master May 27 18:29:15 kroon: possibly the pseudo fix that went in for fchmodat? May 27 18:29:18 * kergoth shrugs May 27 18:30:48 kergoth, possibly ... May 27 18:31:00 it aint lookin' right .. May 27 18:31:17 kroon: perhaps poke seebs about it May 27 18:32:15 -rw-rw-rw- root root 15 ./etc/hostname May 27 18:32:23 that seems odd May 27 18:35:48 yikes May 27 18:39:02 Huh. That's... disturbing. May 27 18:39:26 There could be a typo in there. May 27 18:40:27 Okay, I can't actually tell what this set of & and | do without staring at it. May 27 18:41:34 Hmm. Okay, I think the | and & are wrong, but in a way that shouldn't actually cause a problem. May 27 18:41:41 In that I think I'm masking out some bits twice. May 27 18:42:28 The relevant change is that PSEUDO_DB_MODE(fs_mode, user_mode) changed from masking out 0700 from the filesystem mode, and masking in 0700 from user_mode, to masking out/in 0722. May 27 18:42:50 Ohhh. May 27 18:43:09 So, the underlying change is: Pseudo has started masking out 022 bits in the underlying filesystem. May 27 18:43:28 It's always masked in 0700, because otherwise if you do a chmod 0 of a file, you can't write to it anymore, but root should be able to write to it. May 27 18:43:50 I started masking out 022 because of concerns over someone inserting files in an 0777 directory during filesystem assembly. May 27 18:44:06 *pondering* May 27 18:44:50 But even then, you should not see 022 bits being added by anything. If you issue a chmod(0777), what should happen is: May 27 18:44:59 * The actual filesystem write will use 0755. May 27 18:45:19 * The write to the database will check the filesystem mode, mask out 0722, and mask in (0777 | 0722). May 27 18:45:56 If you do 0755, you should get 0755 on disk, and (0755 & ~022) | (0755 & 022), which should just be 0755, in the database. May 27 18:46:28 So the only way the 022 bits should end up in the database would be if they're in the mode argument actually specified, I think. May 27 18:46:43 *pondering* May 27 18:46:50 Oh-hoh. But I just realized a thing. May 27 18:47:11 Which is I bet that in some cases, you're going to be creating a file, and *specifying* mode 666, and relying on umask to mask those bits out. May 27 18:47:29 So I probably need to actually consider umask now. Grr. May 27 18:48:53 whee May 27 18:52:35 If a mode is specified, wouldn't the caller expect that mode to be set regardless of umask? May 27 18:53:15 I think the answer is yes for chmod, no for open. May 27 18:53:30 ah May 27 18:58:12 So, kroon, you're quite right, thank you. May 27 19:31:40 Okay, I've sent out a patch. It passed what testing I did in the pseudo tree, and I'm pretty sure it will apply cleanly and all that, but... I would not at all mind second opinions from people who are good at sanity-checking code, since my confidence in this code has obviously been too high in the recent past. May 27 19:53:11 seebs: I can't help but wonder if pseudo would benefit from unit testing May 27 19:53:49 It might well! May 27 19:54:39 Although I read a fascinating thing recently arguing that a whole lot of unit testing is actually pretty worthless. But pseudo has a lot of stuff that really ought to be testable and be getting tested more. May 27 19:54:54 we have unit tests within pseudo May 27 19:55:10 It just seems like it'd reduce the risk of regressions May 27 19:55:13 but as bugs are found unit tests simply need to be added.. (or someone who has the time can add additional ones they suspect of issues) May 27 19:55:26 (pseudo has make test) May 27 19:55:27 yeah, true, you have to be vigilant about that May 27 19:56:10 it's pretty hard to argue that test suites are actively harmful in the general case May 27 19:56:13 but now, pizza! May 27 19:56:38 * rburton just wiped out a autoconf patch we've been carrying since 2004 that is actively harmful to building software May 27 19:56:46 awesome May 27 19:57:01 we need to reduce how much we deviate from upstreams, particularly with natives May 27 21:30:29 hello May 27 21:34:26 hello, is anyone available to answer a question? May 27 21:35:19 Don't ask to ask, just ask, and wait around and see if someone responds. not everyone sits here staring at an idle irc channel. folks come and go from their computers. irc is an asynchronous medium, at least for folks that stay connected May 27 21:37:10 seebs, was away from keyboard, i'll test the fix you posted May 27 23:42:45 seebs, ping May 27 23:45:29 ack May 27 23:46:29 seebs, things look better with your fix applied. however, i still see a change for directory permissions in some places. for instance, /usr/lib/ssl has 777 perm May 27 23:46:37 Interesting. May 27 23:47:09 There is a *possibility*, though it's not high on my list, that there could be cases where the fixes to pseudo have fixed things which were previously fortuitously-broken. May 27 23:47:27 It's only directories. I have a diff from buildhistory to list the exact dirs that changed, if this would help May 27 23:47:44 The thing that originally caused this was the discovery that pseudo's implementation of fchmodat was in fact causing gnu tar to extract directories mode 700, hiding a bitbake/oe-core bug that was making some of them 777. May 27 23:48:10 aha May 27 23:48:49 But usr/lib/ssl is a directory that wouldn't have been affected by that oe-core bug, SO, it may still be mine. May 27 23:49:17 hmm, can I check this. the perm. listed in a .ipk file should match whats in the generated filesystem.. ? May 27 23:49:28 I am sorry to do this to you, but I'm sort of overwhelmed today, do you have the time to try to narrow this down or get a rerproducer? May 27 23:49:38 Yes, in theory those should match. May 27 23:50:05 The intent is that the filesystem mode should be (db_mode | 0700) & ~022. May 27 23:50:05 seebs, no worries, this is no showstopper for me personally May 27 23:50:26 And db_mode should be what you specified, either directly for chmod, or an open/mkdir/mknod mode & ~umask. May 27 23:50:39 The previous behavior did not have the ~022. May 27 23:51:00 But once someone pointed it out, I started thinking about what happens if another user, without root privs, has access to a machine that's assembling a rootfs. May 27 23:51:10 And a package is supposed to contain a directory that is supposed to be 0777 *on the target*. May 27 23:52:57 So far as I know, though, mkdir() should be getting umask properly masked out, I'm masking that out before either the filesystem mkdir() call or the record in the db. Hmm. May 27 23:53:29 Well. May 27 23:53:33 Nevermind, I found a reproducer. May 27 23:53:39 umask 0, mkdir a, umask 022, mkdir b. May 27 23:53:48 Not doing what I expect and I don't immediately see why. May 27 23:54:46 seebs, i'm sorry but I don't think I'm of much help in this area .. May 27 23:55:06 No worries. I can reproduce it at least sometimes, so I'll investigate further. May 27 23:55:31 seebs, thanks May 27 23:57:34 * kergoth gets the feeling that maintaining pseudo has become a source of pain :) May 27 23:57:39 d'oh May 27 23:57:45 Soooo. May 27 23:57:57 That carefully-written "mode = mode & ~pseudo_umask" May 27 23:58:06 Is inside an #ifdef for PSEUDO_NO_REAL_AT_FUNCTIONS May 27 23:58:09 own fault May 27 23:59:33 kroon, I can send out a new patch in a bit, but in the mean time: Look at the patch to mkdirat.c. May 27 23:59:53 Note that it adds two new lines under the heading "#ifdef PSEUDO_NO_REAL_AT_FUNCTIONS". Move them just above the #ifdef, and it should work. May 28 00:00:09 And I even wrote a little regression test for this. A regression test which, sadly, did not test mkdir. May 28 00:02:52 hmm, too little context to patch the patch ? May 28 00:03:55 seebs, I'll try once it hits the mailing list. gotta get some sleep now May 28 00:04:04 Okay. Sleep good, and thanks for the timely report. May 28 00:04:29 no problem May 28 00:11:06 Okay, that looks right. sgw_, please feel free to ignore the patches I sent earlier today, and use the new one that fixes that quirk. May 28 00:56:36 Hello . . . I am trying to learn the Intel Galileo. I was just over at #intel, and was directed to here. I am trying to install firmware for a wireless card, following: < http://www.malinov.com/Home/sergey-s-blog/intelgalileo-addingwifi >, but it is not loading. Apparently there is not a service that looks in the directory to find load a new driver. May 28 00:57:07 I am also interested in expanding the size of the image file, how can I do that? **** ENDING LOGGING AT Wed May 28 02:59:58 2014