On Thu, May 13, 2010 at 11:37:15AM +1000, James Cameron wrote:
> I've not yet figured a way to call res_init() from python. ;-(
I've figured that out, tested it, and written it up on
http://bugs.sugarlabs.org/ticket/1940
--
James Cameron
http://quozl.linux.org.au/
__
On Wed, May 12, 2010 at 03:18:07PM -0400, Martin Langhoff wrote:
> Clearly, some python lib caches stale DNS resolver data, and refuses
> to let go, but we didn't know where the problem was.
I've sussed it. libc and Python. Consider this reproducer, which uses
the same underlying library methods
On 12 May 2010 16:18, Martin Langhoff wrote:
> Clearly, some python lib caches stale DNS resolver data, and refuses
> to let go, but we didn't know where the problem was.
>
> The anaconda folks have just hit the same prob, and fixed it. We
> probably need to do the same on the appropriate NM event
Hi Lists,
A while ago dsd reported that after an initial "failed" registration,
it registration was broken. This turned out to be after registering
with no network, or with an invalid network. This is tracked in
http://bugs.sugarlabs.org/ticket/1940 (and in a few places in OLPC's
trac too).
Clear
On Tue, May 11, 2010 at 12:47 AM, James Cameron wrote:
> On Mon, May 10, 2010 at 05:33:07PM +0100, Tiago Marques wrote:
> > On Mon, May 10, 2010 at 7:37 AM, James Cameron wrote:
> > On Sat, May 08, 2010 at 05:24:00PM +, Tiago Marques wrote:
> > > I was just looking into this and the
On 11 May 2010 18:03, Bernie Innocenti wrote:
> I just added the pulseaudio-module-x11 package.
>
> The name is a bit misleading: its purpose is to autostart the pulseaudio
> deamon from the gnome session (and load the x11 modules as well).
Thanks. We've been trying to avoid PulseAudio for now, a
On Wed, May 12, 2010 at 1:46 AM, James Cameron wrote:
> With the 250Mb test I've been doing, this causes 8 seconds in dd, 147
> seconds in sync, and a nice distribution of write latencies (largest
> samples 0.2s 0.1s 44ms 15ms 8ms, median 85us, smallest sample 80us).
Great! Must say that dirty_ra
On 10 May 2010 18:17, Kushal Das wrote:
> It should work as I never switched to to new toolbar API.
v19 confirmed working and fixes those 2 issues. I marked this as an
update for OLPC builds and La Rioja. Thanks!
Daniel
___
Devel mailing list
Devel@lis
On 12 May 2010 09:36, Paul Fox wrote:
> i understand that hardware does a lot of filtering. i was
> referring specifically to the 1.5's current lack of wake-on-arp
> (thank you for making me realize there's no specific bug open for
> this issue -- though it's buried in #9535)
Filed #10157, speci
john wrote:
> > ...the biggest
> > problem area in terms of suspending and not coming back is the
> > network, and without "wake-on-precisely-what-i'm-waiting-for",
> > that's problematic.
>
> Most wireless and Ethernet chips can be configured to
> ...the biggest
> problem area in terms of suspending and not coming back is the
> network, and without "wake-on-precisely-what-i'm-waiting-for",
> that's problematic.
Most wireless and Ethernet chips can be configured to interrupt or
wake on preci
11 matches
Mail list logo
