**** BEGIN LOGGING AT Mon Dec 12 02:59:56 2011 Dec 12 10:30:04 morning all Dec 12 10:30:27 morning Dec 12 10:32:21 hi RP__, JaMa, all Dec 12 10:32:42 morning Dec 12 10:35:10 dvhart: please, when you're around ping me Dec 12 10:47:23 gm Dec 12 15:40:55 otavio: looks like we're both seeing the same issue with connman and talking to sameo ;-) Dec 12 15:41:34 RP__: heh Dec 12 15:41:53 RP__: if you want, you can leave it to me to handle as it is a blocker for me Dec 12 15:42:16 otavio: ok, its also turning the autobuilder red ;-) Dec 12 15:43:24 RP__: and I have some changes for it queued up too Dec 12 15:43:29 RP__: is it failing to build? Dec 12 15:43:39 RP__: do you have a log that I can take a look? Dec 12 15:48:28 RP__: the connman fixes I have queued are https://github.com/OSSystems/oe-core/compare/7ec7e26d...master Dec 12 15:49:03 RP__: but the last one needs to be tested as it doesn't fail to build here so I couldn't be sure if it does work too Dec 12 15:50:06 otavio: Its failing to run the sanity tests Dec 12 15:50:25 RP__: due the lack of network? Dec 12 15:50:27 otavio: e.g. http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/274/steps/shell_22/logs/stdio Dec 12 15:50:37 otavio: network comes up then disappears (when connman loads) Dec 12 15:50:38 RP__: this one I am trying to fix with sameo Dec 12 15:51:13 otavio: btw I tried qconnman over the weekend, works well although it did show an extra "TextLabel" item in the technologies list Dec 12 15:51:25 otavio: That header fix doesn't look right Dec 12 15:51:41 otavio: it can't be the problem as the headers are always built before the toolchain Dec 12 15:52:35 bluelightning: please test the today's one. Gustavo has did some fixes and this reported issue seems to be OK too Dec 12 15:52:48 RP__: but is it available in sysroot too? Dec 12 15:52:53 otavio: yes Dec 12 15:53:00 RP__: humm Dec 12 15:53:04 otavio: Mind trying: dbus-send --print-reply --system --dest=net.connman / net.connman.Manager.EnableTechnology string:"ethernet" Dec 12 15:53:20 RP__: I don't undestand why this built here and fails to dvhart Dec 12 15:53:28 sameo: I did and it works Dec 12 15:53:35 otavio: good. Dec 12 15:54:36 bluelightning: we are working at a systray for it now Dec 12 15:54:57 otavio: cool, it's about time we had a qt4-based frontend :) Dec 12 15:55:14 bluelightning: yes Dec 12 15:55:28 bluelightning: and the code is good too; what helps to get contributors as well Dec 12 15:55:43 sameo: FWIW I changed ethernet from false to true in default.profile and things started working as expected Dec 12 15:56:06 sameo: but then you included a default.profile? Dec 12 15:56:13 RP__: ^ Dec 12 15:56:46 otavio: there is no default.profile with 0.78. Maybe RP had an existing one, and that got translated into the new storage scheme. Dec 12 15:57:05 sameo: yes; that's what I were thinking Dec 12 15:57:16 sameo: my system has no default.profile file Dec 12 15:58:18 otavio: Yes, then ethernet being off is the expected behaviour. Dec 12 15:58:48 sameo: What would be the best way to default to it being enabled? Dec 12 15:59:18 sameo: if adding a default.profile fixes it, it works fine for us Dec 12 15:59:33 sameo: it is just a matter of we make a minimal one and provide it Dec 12 15:59:34 sameo: I'm afraid I don't like something which intentionally deconfigures a network interface :/ Dec 12 16:00:13 RP__: Either send the above d-Bus command, or I can give you a one liner to fix that. Dec 12 16:00:16 RP__: well, connman when started is in charge of network so if it is said to be off it needs to respect it Dec 12 16:00:34 sameo: one liner is better Dec 12 16:00:51 sameo: so it allow the use in read-only-fs Dec 12 16:01:25 sameo: but providing a settings file with the wired enabled shouldn't be enough? Dec 12 16:01:26 sameo: Is the one liner something like the changes in http://git.kernel.org/?p=network/connman/connman.git;a=commitdiff;h=17d0eee00f7a247d279c17cb036672d3c5a67d77 ? Dec 12 16:02:10 RP__: no, reverting this doesn't fix the issue Dec 12 16:02:24 otavio: That should work: http://paste.debian.net/148979/ Dec 12 16:02:40 sameo: right :) Dec 12 16:02:48 otavio: I didn't say revert ;-) Dec 12 16:03:11 sameo: but this is the same of changing settings by hand and restarting connman, right? Dec 12 16:03:28 sameo: Shouldn't those defaults come from the status of the networks when connman starts? Dec 12 16:03:36 RP__: no Dec 12 16:03:41 RP__: nope. Dec 12 16:03:44 RP__: it now enforces all off Dec 12 16:04:05 sameo: What's the reasoning for that? Dec 12 16:04:25 otavio: maybe, I haven't tried it tbh. If it doesn't fix it, I'll get a closer look. Dec 12 16:04:55 sameo: i am trying something Dec 12 16:05:56 sameo: I just did what I said and it fails Dec 12 16:06:15 sameo: it needs to call something to create the network device when wired is true Dec 12 16:06:23 RP__: You either have an existing profile, or you don't. If you don't then we use our default values as we don't expect you to run ConnMan on and off. Dec 12 16:06:33 otavio: What did you say :) Dec 12 16:07:01 sameo: calling via dbus, as it changes the property, it works Dec 12 16:07:06 sameo: So why is all off considered the best defaults? Couldn't they be based on the network device status when its first started? Dec 12 16:07:27 RP__: I don't think so Dec 12 16:07:44 RP__: the idea is to have an easy way to have a known status Dec 12 16:08:03 RP__: All off is the best default because turning radios off should be the user's responsibility. Ethernet is the only non radio based technology here. Dec 12 16:08:14 RP__: and having a different behavior depends on the env it is started doesn't help Dec 12 16:09:32 sameo: does your patch does something different then changing the settings by hand and restarting connman? Dec 12 16:09:39 sameo: radios I can see the argument, ethernet I'm not so sure about. We can patch it easily enough though and carry the patch... Dec 12 16:10:28 RP__: yes; the patch is one solution ... but IMO a way to provide a settings file that works out of box would be better Dec 12 16:10:30 otavio: That's what I'm looking at right now. Dec 12 16:10:56 sameo: from what I see on the code, it does not. Dec 12 16:11:22 RP__: we can have an image that wants wireless on by default Dec 12 16:11:57 RP__: I don't fully disagree with you, but we're trying to be consistent across technologies. Dec 12 16:12:34 sameo: I agree it being off by default ... what i disagree is I changing settings and it doesn't respecting it Dec 12 16:12:48 otavio: I'd agree with that, yes. Dec 12 16:13:04 sameo: if settings works we can provide a settings file and be done with that Dec 12 16:13:27 sameo: and this also allow for people to change the default if needed Dec 12 16:13:41 otavio: Yes, I wouldn't call that a feature. Dec 12 16:13:52 sameo: ? Dec 12 16:14:33 otavio: I think we talked about that already. The ConnMan settings file are not meant to be messed with by users. Dec 12 16:15:34 sameo: here "people" is "system developers" Dec 12 16:16:06 bluelightning: which includes me :) Dec 12 16:16:51 sameo: right, but is it not unreasonable to imagine that for certain types of devices you want certain kinds of network connection to be on at the earliest possible time? Dec 12 16:17:16 bluelightning: certainly not, which is why we have a ConnMan D-Bus interface. Dec 12 16:18:06 sameo: ok, so I have to wait for the dbus service to become available and then send a message? would it not just be simpler to read from a file written at the time the system was created? Dec 12 16:19:20 bluelightning: That's what ConnMan does. And yes, you have to wait for D-Bus to enable a networking technology. Dec 12 16:21:12 sameo: but this is what is not working Dec 12 16:21:31 sameo: I changed the settings by hand and this didn't enable the network Dec 12 16:22:03 otavio: Sending the D-Bus message does work, afaiu. Let me look at a proper fix for you then. Dec 12 16:24:21 sameo: yes; dbus works. Dec 12 16:24:24 sameo: ok :-) Dec 12 16:24:56 bluelightning: I think we're all at same page now ;-) Dec 12 16:25:53 otavio: FWIW, the patch sameo posted does solve the problem for ethernet at least Dec 12 16:26:17 otavio: I'll likely merge that as a short term make this work and stop things breaking fix... Dec 12 16:26:21 RP__: right but it doesn't allow us to override how it ought to be done at first boot Dec 12 16:26:48 RP__: couldn't you wait for few more minutes until he does cook a patch for the settings file? Dec 12 16:27:05 otavio: how do you mean this doesn't allow us to override on first boot? Dec 12 16:27:21 RP__: and remember to remote everything from /var/lib/connman/* for testing Dec 12 16:27:48 RP__: I do believe his patch shouldn't work in a really clean system Dec 12 16:27:57 otavio: I just tested it Dec 12 16:28:05 otavio: it works on a totally clean new image just fine Dec 12 16:28:13 RP__: ok then Dec 12 16:28:21 otavio: It doesn't for you ? Dec 12 16:28:44 sameo: I didn't test the patch .. what doesn't work is changing the settings file Dec 12 16:31:33 RP__: I'd like to be able to provide a "profile" for network for a specific machine/image ... and for that I'd need a way to override the settings file for it to work Dec 12 16:33:05 otavio: I don't know what settings files connman uses. I believe default.profile support was taken out and there is some different way of doing that now Dec 12 16:33:31 RP__: yes; and this is what sameo and I are discussing and found that it is broken Dec 12 16:33:46 RP__: that's why I asked you to hold this patch Dec 12 16:37:42 otavio: Is this something that is going to get fixed imminently? As far as I can tell, we can address that problem in a follow up? Dec 12 16:38:52 RP__: afaik sameo is looking at it; if he takes too long I agree in fixing it that way for now and do a follow up with a better fix but wait some minutes shouldn't hurt Dec 12 16:39:32 sameo_: Dec 12 16:39:34 [14:33] < RP__> otavio: Is this something that is going Dec 12 16:39:35 to get fixed imminently? As far as I can Dec 12 16:39:35 tell, we can address that problem in a Dec 12 16:39:35 follow up? Dec 12 16:39:37 [14:34] < otavio> RP__: afaik sameo is looking at it; if Dec 12 16:39:40 he takes too long I agree in fixing it Dec 12 16:39:42 that way for now and do a follow up with Dec 12 16:39:44 a better fix but wait some minutes Dec 12 16:39:47 shouldn't hurt Dec 12 16:40:03 grr... lines got splitted heh Dec 12 16:40:07 sorry Dec 12 16:40:11 otavio: I just wiped all my ethernet_* directory, and manually edited the global settings file. It just worked. Dec 12 16:40:31 sameo_: here it does not Dec 12 16:40:34 sameo_: how you did? Dec 12 16:41:00 root@beagleboard:/# find /var/lib/connman/ Dec 12 16:41:00 /var/lib/connman/ Dec 12 16:41:00 /var/lib/connman/settings Dec 12 16:41:13 and Dec 12 16:41:21 root@beagleboard:/# cat /var/lib/connman/settings Dec 12 16:41:21 [Wired] Dec 12 16:41:21 Enable=true Dec 12 16:42:08 [global] Dec 12 16:42:09 OfflineMode=false Dec 12 16:42:09 [WiFi] Dec 12 16:42:09 Enable=false Dec 12 16:42:09 [Wired] Dec 12 16:42:09 Enable=true Dec 12 16:43:46 i just tested it and it didn't work Dec 12 16:44:46 With OfflineMode set to false ? Very strange. Do you have a connman -d log for me ? And let's move to #connman please. Dec 12 16:44:57 sameo_: ok Dec 12 16:47:03 sameo_: this worked ... what is wierd is ... Dec 12 16:47:18 sameo_: the generated file didn't have it Dec 12 16:47:45 otavio: I'm going to merge the workaround since its blocking pretty much all the automated runtime QA atm and I'm going to run out of time if I don't Dec 12 16:47:52 RP__: I'm sending the patch for it Dec 12 16:48:08 otavio: Its ok, I can sort it Dec 12 16:48:16 RP__: For what it's worth, ConnMan now uses a /var/lib/connman/settings file that specifies which technology are enabled by default. Dec 12 16:50:21 RP__: my patch obviously changes the default setting that's written down. If you build images with a custom settings file it will work as well. Just FYI, as I don't know which way is the most convenient for you. Dec 12 16:53:56 sameo_: Thanks, I think its going to be easiest to tweak the default since otherwise this is going to catch people out Dec 12 16:54:31 RP__: testing the patch Dec 12 16:54:57 otavio: which patch? I said I'd sort this? Dec 12 16:55:12 RP__: with the working settings file Dec 12 17:08:43 RP__: a proper fix for this problem: https://github.com/OSSystems/oe-core/commit/7da596cd3246bde6ee359c0c60c0b3857c89403b Dec 12 17:12:32 RP__: crap! You didn't wait few minutes Dec 12 17:13:30 RP__: I am sending a patch reverting your change and adding mine. Dec 12 17:13:41 RP__: your change adds a unneeded patch Dec 12 17:26:24 RP__: https://github.com/OSSystems/oe-core/commit/2e706b6c021d92c19e20a57f2bd43d65fcaabd09 this does the changes to get the settings file in place. Dec 12 17:28:28 seebs, posted the suid binary to linux-kernel for review, discussion thread is here if you're curious: https://lkml.org/lkml/2011/12/7/550 Dec 12 17:41:37 otavio: I don't like the settings file idea for this, think about user customisations and package upgrades Dec 12 17:43:55 RP__: in this case this should be done on postinst ... Dec 12 17:44:10 RP__: but then I don't think it is worth it Dec 12 17:44:16 RP__: do you? Dec 12 17:48:04 otavio: well, it means that the config is hardcoded and overwritten at every upgrade Dec 12 17:48:10 otavio: so no, I'm not taking that patch Dec 12 17:49:29 RP__: not really; it could be done if not existing a previous one but too ugly IMO Dec 12 17:49:40 RP__: the patch seems cleaner in this case Dec 12 17:50:13 otavio: I think so Dec 12 22:58:06 RP__: Hi, still here? Dec 12 22:59:13 RP__: fwiw meta-smartphone is already using u-boot instead of uboot for .inc Dec 12 22:59:28 JaMa: ah, ok Dec 12 22:59:43 JaMa: I was thinking European morning might be a better time to merge it... Dec 12 23:00:09 I don't know about other layers.. maybe someone else is using that .inc too Dec 12 23:00:47 but I've changed ours after Wolfgangs reply Dec 12 23:01:54 JaMa: ok, thanks for the headsup Dec 12 23:02:02 yw Dec 12 23:02:07 JaMa: I guess I should still wait until tomorrow for koen Dec 12 23:03:29 meta-ti and meta-angstrom doesn't use u-boot.inc from oe-core afaik Dec 12 23:04:26 but no problem if you wait until tomorrow :) Dec 12 23:28:31 RP__: send a warning to oe-core mailing list Dec 12 23:28:55 layers maintainers ought to read it and also the devs/users of oe-core will know Dec 12 23:42:19 khem: Its been discussed there already Dec 12 23:54:45 ok. Dec 12 23:55:16 RP__: I am trying to create automatic testing for gcc/eglibc Dec 12 23:55:29 and was wondering to make it autotestable Dec 12 23:55:34 khem: that would rock Dec 12 23:55:44 I have taken some steps bu Dec 12 23:55:46 khem: you've seen our qemu tests? Dec 12 23:55:56 I need to understand them more Dec 12 23:56:26 for for eglibc and gcc there are few manual steps I will need help in automating them Dec 12 23:56:32 meat of it works Dec 12 23:56:45 khem: two ways they can happen - at image generation time or as standalone tests Dec 12 23:56:48 khem: bitbake core-image-sato -c qeumimagetest_standalone Dec 12 23:57:00 khem: Just enable the tests in local.conf as per the comments Dec 12 23:57:01 ok. Dec 12 23:57:18 they need access to build trees Dec 12 23:57:26 since they are cross tests Dec 12 23:57:40 so essentially a qemu should be fired up Dec 12 23:57:41 khem: ouch. We can't just run on the target? Dec 12 23:57:56 RP__: we can but it will then test the compiler on target Dec 12 23:58:02 and we want to test cross compiler Dec 12 23:58:06 khem: ah, I see Dec 12 23:58:23 eglibc we can Dec 12 23:58:34 khem: I'd suggest asking about this on the mailing list and cc Jiajun Dec 12 23:58:46 well again for eglibc it will then use the target compiler to compile/build the tests Dec 12 23:58:59 khem: we probably need to add a test task to the eglibc build process Dec 12 23:59:22 RP__: the last patch I send create s script Dec 12 23:59:27 khem: we can let that depend on something like core-image-minimal, then boot it and run the tests Dec 12 23:59:32 which then when run in build tree does everything Dec 12 23:59:49 khem: "everything"? Dec 13 00:00:01 I mean testing part Dec 13 00:00:09 but it requires some manual setup before Dec 13 00:00:19 right now I am adding that to diagnostic Dec 13 00:00:28 but I would prefer as you said an image target Dec 13 00:01:12 khem: we could boot core-image-minimal or similar and then run commands within it to set it up Dec 13 00:01:25 e.g. it needs nfs-client on target 2. password ssh access 3. glibc build tree mounted at exact location as it is on host Dec 13 00:01:33 RP__: yes Dec 13 00:01:42 passwordless Dec 13 00:02:23 RP__: as a start I have started to put together the running bits together Dec 13 00:02:45 khem: the qemu image pieces we have already do ssh Dec 13 00:02:45 then next would be hook them into auto execution part Dec 13 00:02:51 cool Dec 13 00:03:06 khem: If you can write down the steps needed manually, I think Jiajun might be able to help Dec 13 00:03:23 for eglibc I think if we could build all tests in one go and package them then just run them on target would work too I guess Dec 13 00:03:28 khem: We're also looking at ltp/posix/lsb test automation Dec 13 00:03:34 cool Dec 13 00:04:00 RP__: I already sort of did here http://sakrah.homelinux.org/blog/2011/12/cross-testing-eglibc-regression-testsuite-using-openembedded-coreqemu/ Dec 13 00:04:18 but that is a document under work Dec 13 00:04:28 I will write something similar for gcc-cross Dec 13 00:04:36 khem: cool :) Dec 13 00:04:50 time to see what plumbers are doing Dec 13 00:04:51 ttyl **** ENDING LOGGING AT Tue Dec 13 01:20:13 2011 **** BEGIN LOGGING AT Tue Dec 13 01:22:14 2011 **** ENDING LOGGING AT Tue Dec 13 01:30:04 2011 **** BEGIN LOGGING AT Tue Dec 13 01:32:14 2011 **** ENDING LOGGING AT Tue Dec 13 02:59:57 2011