Re: Can't find shared library libusb
On Fri, Oct 15, 2010 at 05:24:30PM -0200, Emiliano Pastorino wrote:
> I'm trying to use libusb, but I'm getting this behaviour in python:
>
> >> from ctypes.util import find_library
> >> find_library('usb')
> >>
> (returned None)
I see this too on os852, on Debian, on Ubuntu 10.10, and on Fedora 11.
On the other hand, cddl.LoadLibrary worked fine.
An strace of find_library showed ldconfig, gcc and ld were executed, and
this agrees with the documentation:
http://docs.python.org/library/ctypes.html#finding-shared-libraries
--
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
OLPC wireless startup at boot time
DISCLAIMER: I am not asking for help; I am just sharing my thoughts. I've been testing XO-1 with builds prior to 2010. And what I've often noticed, in looking first thing (after booting) at Neighborhood View: XO-icons appear (seen via mesh). Very soon, these icons disappear. The circular mesh-icons pulse - eventually mesh-1 is brought up XO-icons appear (seen via mesh). It is as though this just-started XO-1 system was happy to receive radio signals from other XOs -- but then was told "forget about all that" -- and had to go through a protracted "find what frequency to use" procedure to again establish contact with other XOs on the air. It seems to me -- if the just-started XO (any model) is *already* receiving identity information off the air - why BREAK that connection ? The just-started XO should initially set its frequency to be the same as it was whenever that XO was last used. If at least one *other* radio signal is heard, it should leave that frequency connected -- and depend on the user to intervene (through Neighborhood View) if now this XO should instead be connected to a different station (or frequency). [If there happens to be an user who would prefer the automatic connection to be to the "first ever used" access point (first entry in ~/.sugar/default/nm/connections.cfg), rather than to the "last ever used" access point -- provide a gconf flag setting that keeps the existing connections.cfg usage (it overrides last used connectivity).] The "automatically started by the hardware" (i.e., "first thing" I saw) radio setup should be RESET only if it is on a different frequency than the access point (or non-access point) the XO is expected to reconnect to. I believe that AVOIDING the "reset the radio, and set up the frequency anew for the connection I am looking for" procedure will save a lot of time in the majority of cases. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
os852-xo1 wireless connectivity
>> While troubleshooting a problem I have on os852 xo1 (interface eth0 >> disappears), > You're probably seeing this bug: > http://dev.laptop.org/ticket/10195 > After a very long chase, we fixed it for good in Dextrose by disabling > mesh support: Yes - the symptom looks the same (though I havent seen "USB disconnect") The environment I have in mind as my "ideal deployment", though, is "under the tree" where a number of XO-1 machines are running Fedora9-based builds. I think it would be difficult to persuade their owners to all consent to upgrade to a build which supports ad-hoc. Yet owners who did upgrade will want to collaborate with owners who did not. I am having very good luck running mesh on all kinds of XO-1 builds in my own environment (which connects to an access point through wired ethernet). Thus it came as a surprise to me that when I tested in a different environment (which connects to an access point through wireless), that eth0 would disappear on os852-xo1 with October RPMs. [Back in September, os852-xo1 in that environment kept its eth0.] [Note - I have no difficulty running/using eth0 (or connecting to the AP) if I __manually__ set it up it from the command line -- it is only that Sugar now does not show Access Point icons in Neighborhood View.] For the time being, I will continue to investigate this "eth0 disappears" situation - and will even write an os852 ticket if I find something defective. Regarding my "ideal deployment", I suspect it might be easier to "back" the os852-xo1 build to keep using mesh, than to "forward" previous-year XO-1 owners to start using ad-hoc. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Script to install missing langs?
On Sun, 2010-10-10 at 19:49 -0400, Sayamindu Dasgupta wrote: > > BTW: I was wondering if you know why the Fedora RPMs for Sugar and > > Activities include message catalogs for en and even all the en_* > > variants: > > It was a hack that was used at some points to fix typos in code (eg: > if you had "Wopen" in the source code, you could probably just change > the translation of "Wopen" to "Open" in en_US, since if you changed > "Wopen" to "Open" in the code, all other translations would had to be > updated as well). Yet, do we really need a copy of the english catalog for each existing en_XX variant? It seems like a big waste of space. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: avahi might show confusing IP-addresses for the XOs it reports
On Sun, 2010-10-17 at 08:37 -0500, Mikus Grinbergs wrote: > XO-1 os852 (with updated olpc-powerd) > > DISCLAIMER: This is FYI - I'm sharing my experiences > > While troubleshooting a problem I have on os852 xo1 (interface eth0 > disappears), You're probably seeing this bug: After a very long chase, we fixed it for good in Dextrose by disabling mesh support: http://dev.laptop.org/ticket/10195 Besides this particular bug, we could never get the mesh to work reliably on the XO-1, and at this point I don't believe it will ever happen. The ad-hoc mode covers 99% of the real-world use-cases for the mesh, using a mature, standard protocol. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
avahi might show confusing IP-addresses for the XOs it reports
XO-1 os852 (with updated olpc-powerd) DISCLAIMER: This is FYI - I'm sharing my experiences While troubleshooting a problem I have on os852 xo1 (interface eth0 disappears), I saw strange output from 'olpc-xos -avahi' on a system where eth0 worked (I was using this other system for eth0 comparison): > 0 [~]$ olpc-xos -avahi > Time : 06:44:24 > > 06f4a...@lauva 192.168.1.27Lauva-8 > 55c4a...@purvs fe80::210:60ff:fe15:41dcPurvs-1 > 2733b...@uguns 192.168.1.16Uguns-1 > 11276...@zemes 169.254.9.44Zemes-1 > 11276...@zemes 192.168.1.18Zemes-1 > 0 [~]$ The listing for Zemes (taken on Zemes) is slightly confusing - there are two entries. The one (192...) is for its wired ethernet connection, and the other (169...) is for the automatically-started mesh connection. Does OLPC expect an XO to have only one IP-address ? The listing for Purvs is the one I think is inappropriate. Apparently, Purvs at this time did not have its ethernet software (IPv4) address set - so its ethernet-hardware-derived (IPv6) address got shown. [I do __NOT__ use IPv6 addresses to communicate between XOs.] A little later, Purvs had set up its IPv4 ethernet address (I forget - was that manual, or automatic ?) - now repeating 'olpc-xos -avahi' at Zemes resulted in the appropriate (192...) address for Purvs being reported. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
