buglabs / bug-osgi Goto Github PK

While finishing up the on-BUG JUnit testing bundle for the LCD module, I noticed that while the setBackLight(int val) method was correctly setting the back light to the desired value, it was returning 1 ('Operation not Permitted') rather than 0. On a similar note, the javadoc at http://darner:8085/job/bug-osgi/javadoc/ suggests that the back light values range from 0-7 when, as far as I can see, they range from 0-100.

My code:
http://pastebin.com/u4VcDC9z

This sounds like it should be expected, but as connector has shown us, if there isn't a nice way to handle this exception, everything that relies on the fix breaks.

Will work on a repro with pastes soon. Just wanted to get the issue up before I forgot.

I have a test that prints out a set number of bytes from the getInputStream method in the INMEARawFeed interface. In my 2.1 testing, this would printout the raw NMEA data. For 3.0, It does not appear to print out anything. Again, this may be a problem with me porting my test suite over to 3.0.

Pastes:
Code: http://pastebin.com/RjvLsVWt

After running the automated camera module tests and digging through the printout, it looks like there is a bug with the ICamera2ModuleControl interface. All of the get methods are returning -1 values. Additionally, all of the set methods are also returning -1 for their IOCTL returns. The other camera module interfaces seem to be working correctly. This may be a bug on my end since I am just porting my test suite over to 3.0 for the first time. Let me know if you think that's the case.

-Davis

Pastes:
Example Code: http://pastebin.com/BGZtvWB6
Example Printout: http://pastebin.com/97hRvR8q
-Still trying to work out the formatting on my tests' printouts. This printout shows the returns for the last 'get' method and then the printouts for each of the 'set' methods followed by their errors/failures

Rootfs: 3.0 Build #14

After being connected to the office network for a while, the connection will drop and ifconfig will show a connected wlan0 interface with a bogus IP (not 192.168....). Restarting connman will not fix the issue. So far the only fix I have come up with is to reboot the machine. When it comes back up will will connect with a proper IP and the drop will occur again randomly. @mgrundy believes this is DHCP related and may have to do with expired leases not being handled properly. Either way, he mentioned that it may be a bug in the rootfs, so I thought I would create an issue for it. Let me know what other information I can provide.

Edit: The BUG that is currently experiencing these problems is at hostname officeswarm2 and IP 192.168.0.215 (when it has a correct IP of course).

On OSGi start:

01.13 14:33:22 ERROR Bundle/Modlet error occurred: java.lang.IllegalArgumentException, Invalid sysfs directory: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/5-0017 [34]com.buglabs.bug.bmi (3.0.0)
01.13 14:33:22 ERROR java.lang.IllegalArgumentException: Invalid sysfs directory: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/5-0017
at com.buglabs.bug.sysfs.SysfsNode.(SysfsNode.java:25)
at com.buglabs.bug.module.lcd.ML8953Device.(ML8953Device.java:29)
at com.buglabs.bug.module.lcd.ML8953Device.getInstance(ML8953Device.java:56)
at com.buglabs.bug.module.lcd.ML8953AccelerometerImplementation.(ML8953AccelerometerImplementation.java:22)
at com.buglabs.bug.module.lcd.pub.LCDModlet.start(LCDModlet.java:80)
at com.buglabs.bug.bmi.BMIModuleEventHandler.handleEvent(BMIModuleEventHandler.java:112)
at com.buglabs.bug.bmi.Activator.coldPlug(Activator.java:163)
at com.buglabs.bug.bmi.Activator.frameworkEvent(Activator.java:369)
at org.apache.felix.framework.util.EventDispatcher.invokeFrameworkListenerCallback(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.run(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher.access$000(Unknown Source)
at org.apache.felix.framework.util.EventDispatcher$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:636)
[34]com.buglabs.bug.bmi (3.0.0)

On the BUG, the closest path that exists is: /sys/devices/platform/i2c_omap.3/i2c-3/3-0070/i2c-5/

cat /etc/buildinfo
BUG Linux Build Information
Version: 3.0.1003110016
Build Host: Linux darner 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux
Build User: root
Build Time: Mon Oct 3 04:16:22 UTC 2011
Revision: 84b43f8

Wasn't sure whether to throws this in the Dragonfly repo or here.

Currently, when attempting to connect to a BUG running rootfs 3.0 from Dragonfly 3.0, the sdk claims it cannot connect. Creating a manual connection to the BUG and appending port 8080 onto the end of the address solves this problem. jconolly mentioned something about how the port should be 80 rather than 8080 in addition to Dragonfly defaulting to the correct port so one does not need to create the manual connection.

Again, not sure whether this should be in Dragonfly repo or here.

Right now, if you are to create an app in Dragonfly 3.0 and send it to a BUG containing the 3.0 rootfs, the following error pops up.

"The BUG Application 'Test' has been built for a different Execution Environment than is running on BUG 'barberdt30bug'. Please set the Execution Environment in your application's manifest to match one of: JavaSE-1.6,J2SE-1.5,J2SE-1.4,J2SE-1.3,OSGi/Minimum-1.2,OSGi/Minimum-1.1,OSGi/Minimum-1.0"

Looking at the manifest for the app being sent, I don't see any current implementation of 'Execution Environment' variable, but I may just be missing something simple.

Note: This relates to a separate issue, in which I was sending the app in the first place to see where it was placed within the rootfs. With the new rootfs, I am unsure where 'apps' are supposed to be located. I see the 'build-in' apps, such as the appui and networkingui in the bundle directory, but is this where all apps are to be located (versus the separate 'apps' and 'bundles' directories of the previous rootfs)?

I am noticing that the bundles that I have loaded into /usr/share/osgi/bundle are not being started when Felix starts. Some of the bundles that are loaded stock on the rootfs are also experiencing the same behavior. This isn't much of a problem for my tests since I would actually prefer to start my bundles manually (from the appui) so I can choose what modules are tested at any given time, but I would suspect this is not the desired behavior.

p.s. The bundles are being loaded correctly, just not started.