Re: TamTam packaging
-why are the cpp sources in the MANIFEST and consequently in the xo? At the beginning we TamTam was only one activity with a welcome screen to choose which component to play with. When we were aksed to spilt the activities it was the simplest way for us to manage all activities from one git tree. But all sounds and common images are located only inside TamTamEdit. Ok. But are the c++ sources in common/Util/Clooper/ needed in the final xo? -which versions do you recommend for packaging. Latest are 48 and 49 , depending on the activity Always the latest... even though i'm on the way to make major changes in the way TamTam handle resources (mic recording, synthlab sounds...) to respect OLPC security policy. These changes will complicate once more the port to others system... I got them to build and start on Ubuntu but I have no sound The lib is acsound64 not acsound in debian/ubuntu so the link flag needed a change to rebuild the aclient.so instead of using the one in git. I don't think using the aclient is the better way to make it work on Debian. This client was build very tight to save cpu cycles on the XO. The better way is to use the Python API for Csound... (with the API, don't forget to remove -n flag (no sound) in tamtamorc.csd). Maybe James can tell you more about aclient.so I did not look closely so did not realize that python-csound is not used. Anyway I'd rather keep changes from the XO version at a minimum for now and not add extra code. The goal is to get it working first. One important issue I forgot to mention yesterday: there are no licensing headers or copyright files in the sources except in Clooper/audio.cpp which comes from ALSA. Can you when time permits add any kind of copyright notice along the source files? It is impossible to upload to either Debian or Ubuntu otherwise. thank you Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Severe new bug in firmware Q2D13?
[EMAIL PROTECTED] said: That voltage has to be read with DC power and the main battery removed to be meaningful. There is a trickle charging circuit in play if there is any other source of power. Good catch. Mine's been unplugged and without battery for a few hours. It's still reading 3.3 V. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to use Salut?
On Wed, Apr 16, 2008 at 5:41 PM, Dafydd Harries [EMAIL PROTECTED] wrote: If there is an internet connection, the laptop will only try using Salut after it has tried to connect to the Jabber server. Perhaps connecting to the Jabber server is taking a long time to time out, so it's not trying Salut? If there is an internet connection (address not starting with 169.254) on msh0, *then* it is assumed you are connected to a school server via the mesh, and *then* salut is not started while it tries to connect to the jabber server. If you're on a regular access point, salut will start immediately. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
trying to customize nand images with block2mtd
hey guys, I am trying to customize a os703 image without booting up into Sugar. I am using the following currently, but getting some stttrrrnge errors. http://wiki.laptop.org/go/Mounting_jffs2_images here is what I have done losetup /dev/loop0 os703.img modprobe block2mtd block2mtd=/dev/loop4 cat /proc/mtd# inspect status mkdir mtd modprobe jffs2 mount -t jffs2 mtd0 mtd make changes then umount /mnt/mtd modprobe -r block2mtd losetup -d /dev/loop0 How to create new crc: git clone git://git.fedoraproject.org/git/pilgrim cd pilgrim/crcimg make ./crcimg myfile.img Then I take my new images and copy it to an XO with the command copy-nand u:\newimage.img It successfully writes over the current flash image Then I type in boot at the Forth prompt. This produces a ton of JFFS2 warnings bad summary on node on boot and ends in a page fault Any ideas? The Mounting jffs2 images wiki page says the following If you want to write to the image, you may need to pad it with several blocks of 0x bytes. I have no idea how to do this. Would this solve my problem and if so, could someone explain to me how to do it? thanks -- Bryan W. Berry Systems Engineer OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] support battery-charge-state-dependent battery frame icon
On Thu, Apr 17, 2008 at 6:00 AM, Eben Eliason [EMAIL PROTECTED] wrote: So, I'm not the authoritative source on this, but I'll toss in my thoughts... Now... this is getting out of control... designer doing reviews... !?! :P (Thanks Eben) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New Planning Thoughts draft.
Available at a wiki near you: http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_2 The important changes since the last version are: * a new foreword, with a rich analogy describing our present situation, * a new (tentative) commentary/criticism of our release process to date, * a coherent definition of what we want when we talk about software stability, reliability, and predictability that can be used to judge many proposed changes, and * a strong suggestion that we apply Greg's algorithm [1] to the problem of figuring out which changes to work on in what order. [1]: http://tinyurl.com/3jfwah Finally, I'd like to inform everyone that as I work from the bottom up toward an acceptable plan, Kim is working from the top down to meet us by interviewing the other functional directors in order to keep us informed of their desires. She and I are meeting regular in order to harmonize the results of our interviews and we look forward to having a rough draft that can be presented to those directors sometime next week. Questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Planning Thoughts draft.
On Thu, Apr 17, 2008 at 11:23 AM, Michael Stone [EMAIL PROTECTED] wrote: Available at a wiki near you: http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_2 Making quick progresses, yay! A couple of thoughts about the release process: * Reducing the scope of the releases is a reasonable solution to deal with lack of QA resources. But I think on the medium term we need to scale. The developer community will contribute in direction which we don't anticipate. We cannot and should not force community focus on a limited number of aspects. We should instead aim to leverage the community also in the QA process, which is a big strength of open source development. * Smaller-and-faster (focused) releases are an interesting idea but I think they are also quite a challenge. We need to ensure that we are able to parallelize the various streams. For example, if we do a release which focuses on networking, someone will keep working on UI and performance at the same time. How do we avoid clashes? Having multiple streams going on concurrently certainly complicate the development process. I don't have previous experience of this kind of development. We can try to go through it and try to anticipate how it would work in practice. Or even better maybe someone have experience that can be shared here. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] support battery-charge-state-dependent battery frame icon
[apart from some feedback on your first two comments I can get a new
patch out later today -- so can you focus on those sections please?]
On Thu, Apr 17, 2008 at 12:00:48AM -0400, Eben Eliason wrote:
So, I'm not the authoritative source on this, but I'll toss in my thoughts...
+lvl = self._level
+secondary_text = ''
+status_text = '%s%%' % lvl
I would avoid declaring variables unless they really make serve a
purpose.
The purpose of this variable (lvl) is twofold:
1) Read things once: it's not threadsafe to access self._level twice
and expect to read the same value. Yes, python doesn't have the same
thread support as other languages, and maybe self._level doesn't
change very often at all, but why write code that once in a while, for
one or two people, is going to make the text show 50% and the slider
show 49%? It'd be messy, and it's easy to avoid by just reading the
_level once;
2) once I started getting a little (yes, overly) paraoid by #1 (I
originally wrote the code just as you've recommended, FWIW :)), I
realized some would think it's a bit nicer to not have multiple reads
for the same value, and that a shorter variable name would make the
code indentation a bit nicer. This point is admittedly very minor,
but adds a tiny bit of weight to #1.
The purpose of status_text and secondary_text is different: rather
than set them in each branch of the conditional, or (I think worse,
but IIUC you prefer), do something with it inline in each branch, I
just mutate it in the (few) branches of the conditional as appropriate
and then do something, once, with it.
Compare these structures:
1.
sometext = ''
if a:
...
elif b:
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
...is, all other things being equals, better than (less duplication):
2.
if a:
sometext = ''
...
elif b:
sometext = ''
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
...and probably even more better (ugh, but perhaps you know what I
mean) than:
3.
if a:
dosomething('')
...
elif b:
dosomething('')
if b1:
...
else:
dosomething('foo')
I think #3 is particularly bad because you now make a maintainer do
this:
if a:
dosomething('')
dosomethingelse('')
...
elif b:
dosomething('')
dosomethingelse(') -- haha look...found this bug when proofreading!
if b1:
...
else:
dosomething('foo')
dosomethingelse('foo')
rather than just:
sometext = ''
if a:
...
elif b:
if b1:
...
else:
sometext = 'foo'
dosomething(sometext)
dosomethingelse(sometext)
Am I overlooking some other consideration(s)?
+if lvl = 15:
+secondary_text = _('Very little power remaining')
This is probably the correct place to fire off a notification, and
perhaps even badge the icon with a warning badge. Of course, all of
the necessary components aren't in place for this to work perfectly
just yet...not sure if it's worth adding at this point. It would
depend, at a minimum on Eric Burns' forthcoming notification patch for
specifying the appropriate screen corner.
I could add the badge and the notification, sure. Do you want that in
a separate patch? Adding a badge is trivial (you want the
emblem-warning.svg, I guess, not emblem-notification.svg or anything
forthcoming, right?). It'd be a bit quicker if I could do the
notification in a separate patch, I think, as I'm not sure how to do
that yet.
+minutes = _('m')
+hours = _('h')
+#TODO: make this less of an wild/educated guess
+minutes_left = int(lvl / 0.59)
+if minutes_left 60:
+guess_text = '%s%s' % (minutes_left, minutes)
+else:
+hours_left = minutes_left / 60
+mins_leftover = minutes_left % 60
+guess_text = '%s%s%s%s' % (hours_left, hours,
+ mins_leftover, minutes)
I think I'd prefer the format 1:23 remaining, without the extra 'h'
and 'm' business.
Ok -- your design had the 3 hours remaining, so I probably shouldn't
have played with your design without asking you first. I'll change it
to just H:mm (as you also request with your code below).
Also, I'd use a more descriptive variable name like
time_left; guess_text is somewhat ambiguous, apart from the context.
Sure -- I wanted the variable name to scream this code knows that
it's not doing a good job of calculating the time remaining, but of
course it's a very tiny thing to change.
In fact, I might forego that string completely in favor of calculating
hours_left and mins_left variables, and then directly doing:
self.props.secondary_text = '%d:%.2d %s' + (hours, mins,
_('remaining'))
Cool! Will do.
+mins_leftover = minutes_left % 60
I would personally just overwrite the minutes_left variable here
Re: Battery life estimation considered impossible?
Martin Dengler wrote: 3. minutes_left = battery_capacity_pct / 0.59. From [1]. The magic constant is about 1.2 pct of battery capacity = 2 minutes of power; this is what I've observed and consistent with other reported capacities I've seen; but of course the approach is fatally flawed. Sorry I'm a bit late to respond. My attention has been elsewhere. Accurate battery life estimation is going to present a challenge. The first issues that come to mind are: - The (eventual) large fluctuation of power draw once our power management efforts mature. Sometime soon the XO will be constantly fluctuating between 2 Watts during auto-suspend and the 7W when its crunching. Since this will be driven by the user's usage habits it will be difficult to predict. Once this starts happening the above algo will break. - The XO has 3 different batteries and 2 different chemistries each with a different capacity. - In classroom situations that use 2 batteries/XO and the Multi-Battery charger you may end up with a different battery every cycle. - The available capacity of the battery changes based on the temperature. LiFePO4 less so. NiMh more so. - The capacity of the battery reduces every discharge/recharge cycle. Design specs for the battery are 50% left after 2000 cycles which works out that you can expect up to 10% loss per year. The degradation curve for LiFePO4 is pretty much linear wrt time. I've not seen a curve for NiMh. NiMh is tricky since the ambient temp while charging has a large effect on its degradation. The power draw is of course going to dominate the above issues and the good news is that by using the data from accumulated current register inside the battery you can get a very accurate reading on how much juice you have used between any 2 instances in time. (Assuming the battery isn't removed) So if you were to take ACR readings and build up some sort of usage profile then that might get you close enough. Batteries are also uniquely identifiable since the gas gage chip has a 64-bit unique id and we repoort that in the battery driver. So I suppose you could build up a little database over time of the profiles of all the batteries the XO has seen. I use the ACR and battery ID in my power profile script. http://dev.laptop.org/~rsmith/olpc-pwr_log See here for how to process ACR data: http://dev.laptop.org/~rsmith/process-pwr_log.py I do think some sort of current power draw indication and history would be a useful item. In particular it would be useful in assisting the user when working with a solar panel. To maximize your results on solar you have to align the panel with the sun. Watching the power draw should allow you to figure that out. It just needs a few extra options for setting a faster sample rate, telling ohm not to suspend, and then present some sort of workload that makes the power draw fairly constant. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Planning Thoughts draft.
Peanut gallery comments... On Thu, Apr 17, 2008 at 12:02:02PM +0200, Marco Pesenti Gritti wrote: On Thu, Apr 17, 2008 at 11:23 AM, Michael Stone [EMAIL PROTECTED] wrote: Available at a wiki near you: http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_2 Making quick progresses, yay! A couple of thoughts about the release process: * Reducing the scope of the releases is a reasonable solution to deal with lack of QA resources. But I think on the medium term we need to scale. The developer community will contribute in direction which we don't anticipate. We cannot and should not force community focus on a limited number of aspects. I'm not sure the last sentence I quoted above gets the prominence it deserves. Focus from OLPC doesn't mean enforcing focus on the community (probably this is uncontentious but the more it's in the foreground of people's thoughts, the easier it can be to see the benefits/costs of current proposals). * Smaller-and-faster (focused) releases are an interesting idea but I think they are also quite a challenge. We need to ensure that we are able to parallelize the various streams. For example, if we do a release which focuses on networking, someone will keep working on UI and performance at the same time. How do we avoid clashes? Having multiple streams going on concurrently certainly complicate the development process. I don't have previous experience of this kind of development. In my experience, with quality developers and a bit of an edge towards - during the development cycle only - seek forgiveness not permission combined with developers being a bit less prickly about their code than is their normal wont[1], smaller-and-faster has an amazing (ly good) effect on productivity and quality. I don't think OLPC lacks quality developers and it appears there is social momentum building within OLPC for this approach (without this grass-roots support IMO smaller-and-faster is doomed). So adopting a smaller-faster focus while making it easier for the community to contribute on a more even level with internal developers is very much an approach that finds a very hospitable situation. This is an opportunity with a lot of potential... Marco Martin 1. In case I'm not being clear, an extreme example of the combination of forgiveness-not-permission and the requirement to be a bit less prickly that I'm envisioning are mob-developed[2, 3] projects. I'm not saying that extreme approach is warranted (or being proposed) here. 2. http://repo.or.cz/about.html 3. The way out of this predicament is this simple: Set up a fairly clear architectural direction, produce a decent first cut at some of the functionality, let loose the source code, and then turn it over to a mob. http://www.dreamsongs.com/MobSoftware.html pgpTRkEhyatlw.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Planning Thoughts draft.
On Thu, Apr 17, 2008 at 12:02 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: * Smaller-and-faster (focused) releases are an interesting idea but I think they are also quite a challenge. We need to ensure that we are able to parallelize the various streams. For example, if we do a release which focuses on networking, someone will keep working on UI and performance at the same time. How do we avoid clashes? Having multiple streams going on concurrently certainly complicate the development process. I don't have previous experience of this kind of development. We can try to go through it and try to anticipate how it would work in practice. Or even better maybe someone have experience that can be shared here. I see this too as a hard problem and don't really have experience neither. What I would expect is that working on frequent time-based releases with features slipping as needed works best for projects like linux distros, where slipping a feature grossly means not updating a set of packages to the latest stable version. That works because those packages generally depend on other parts of the system in a quite controlled way, through well-known and very stable APIs. In our case, the sugar codebase is much smaller, and those few components are more tightly coupled and the APIs are still immature. The codebase being small means that the possibility of a conflict when merging features is much bigger. All this overhead with merging and unmerging features means lots of work for the small development team. Also means much more work for the QA team, that cannot test each feature separately and expect the final product with the final features in it to work as expected without retesting everything. I'm not advocating for omnibus releases, just a general comment. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery life estimation considered impossible?
On Thu, Apr 17, 2008 at 06:40:21AM -0400, Richard A. Smith wrote: Martin Dengler wrote: 3. minutes_left = battery_capacity_pct / 0.59. [. . .] but of course the approach is fatally flawed. Sorry I'm a bit late to respond. My attention has been elsewhere. It was well worth the (very small) wait. Thanks. Accurate battery life estimation is going to present a challenge. The first issues that come to mind are: [. . .] The power draw is of course going to dominate the above issues and the good news is that by using the data from accumulated current register inside the battery you can get a very accurate reading on how much juice you have used between any 2 instances in time. (Assuming the battery isn't removed) So if you were to take ACR readings and build up some sort of usage profile then that might get you close enough. Notwithstanding the high accuracy and interest value of your list of issues, the statement that power draw dominates and the ACR data would very useful is very promising. Batteries are also uniquely identifiable since the gas gage chip has a 64-bit unique id and we repoort that in the battery driver. So I suppose you could build up a little database over time of the profiles of all the batteries the XO has seen. Cool. I wonder where such code should live - presumably not sugar's model/devices/battery.py? I use the ACR and battery ID in my power profile script. http://dev.laptop.org/~rsmith/olpc-pwr_log See here for how to process ACR data: http://dev.laptop.org/~rsmith/process-pwr_log.py Cool... I do think some sort of current power draw indication and history would be a useful item. So much so that extending the battery UI might be interesting? If not, see my next comment... In particular it would be useful in assisting the user when working with a solar panel. To maximize your results on solar you have to align the panel with the sun. Watching the power draw should allow you to figure that out. It just needs a few extra options for setting a faster sample rate, telling ohm not to suspend, and then present some sort of workload that makes the power draw fairly constant. Sounds like enough of a spec for an activity. Martin pgpt5Z4QgoVzf.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Planning Thoughts draft.
On Thu, Apr 17, 2008 at 1:23 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: I see this too as a hard problem and don't really have experience neither. What I would expect is that working on frequent time-based releases with features slipping as needed works best for projects like linux distros, where slipping a feature grossly means not updating a set of packages to the latest stable version. Even linux distro (Fedora at least,), doesn't actually do focused releases. Roughly, they set a timeframe and they get in everything which is ready by that date. This is very easy for a linux distribution. It would be harder on the Sugar codebase but still very much feasible, it's the same approach of GNOME releases. Though Michael proposal goes a step further. We would be focusing only on one (or a very limited number) of goals per release. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TamTam packaging
Le 08-04-17 à 02:49, Jani Monoses a écrit : -why are the cpp sources in the MANIFEST and consequently in the xo? At the beginning we TamTam was only one activity with a welcome screen to choose which component to play with. When we were aksed to spilt the activities it was the simplest way for us to manage all activities from one git tree. But all sounds and common images are located only inside TamTamEdit. Ok. But are the c++ sources in common/Util/Clooper/ needed in the final xo? No. -which versions do you recommend for packaging. Latest are 48 and 49 , depending on the activity Always the latest... even though i'm on the way to make major changes in the way TamTam handle resources (mic recording, synthlab sounds...) to respect OLPC security policy. These changes will complicate once more the port to others system... I got them to build and start on Ubuntu but I have no sound The lib is acsound64 not acsound in debian/ubuntu so the link flag needed a change to rebuild the aclient.so instead of using the one in git. I don't think using the aclient is the better way to make it work on Debian. This client was build very tight to save cpu cycles on the XO. The better way is to use the Python API for Csound... (with the API, don't forget to remove -n flag (no sound) in tamtamorc.csd). Maybe James can tell you more about aclient.so I did not look closely so did not realize that python-csound is not used. Anyway I'd rather keep changes from the XO version at a minimum for now and not add extra code. The goal is to get it working first. When tested on jhbuild, we've got erratic sound.Good luck! One important issue I forgot to mention yesterday: there are no licensing headers or copyright files in the sources except in Clooper/audio.cpp which comes from ALSA. Can you when time permits add any kind of copyright notice along the source files? It is impossible to upload to either Debian or Ubuntu otherwise. Absolutely! Thanks for the warning... thank you Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
How can I set my activity with P_DOCUMENT_RO enable?
If I can write entry in the Journal, can I assume that I have P_DOCUMENT permission? How can I retrieve objets from datastore? Thanks Olivier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: More planning thoughts
Your scale is 1-10? 1 being low and 10 being high? What is mesh? The transport layer? It is curious that you think that collaboration is currently the most tolerable feature. From what perspective? In the field, I find no other feature that causes as much frustration to end users as the instability of collaboration system. Everyone has very high expectations for it--perhaps higher than anything else--but then it just doesn't work. In any case, I'd recommend another column in your table: how important is this feature to the laptop use case: learning? -walter 2008/4/16 Jameson Chema Quinn [EMAIL PROTECTED]: Here's my POV on the issues... issue affects all users affects all developers radical change suggested tolerability of current state of affairs how hard to improve power management 6 2 ? 5 3 mesh 6 4 6 4 5 both of the above together 7 datastore 8 8 10 3 5* sugar UI 8 4 (many changes are inside sugar) 5 6 3-5* collaboration 6 6 6 7 3* compatibility/ interoperability 2 7 4 (mostly clever hacks) 6 3 performance 8 2 4 6 5 * Requires work by activity developers. ... As you can probably see from the above table, I'd vote putting the datastore first in line, as it is the one issue which causes data loss. More later, Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] support battery-charge-state-dependent battery frame icon
On Thu, Apr 17, 2008 at 6:19 AM, Martin Dengler
[EMAIL PROTECTED] wrote:
[apart from some feedback on your first two comments I can get a new
patch out later today -- so can you focus on those sections please?]
On Thu, Apr 17, 2008 at 12:00:48AM -0400, Eben Eliason wrote:
So, I'm not the authoritative source on this, but I'll toss in my
thoughts...
+lvl = self._level
+secondary_text = ''
+status_text = '%s%%' % lvl
I would avoid declaring variables unless they really make serve a
purpose.
The purpose of this variable (lvl) is twofold:
1) Read things once: it's not threadsafe to access self._level twice
and expect to read the same value. Yes, python doesn't have the same
thread support as other languages, and maybe self._level doesn't
change very often at all, but why write code that once in a while, for
one or two people, is going to make the text show 50% and the slider
show 49%? It'd be messy, and it's easy to avoid by just reading the
_level once;
You make a good case. =)
2) once I started getting a little (yes, overly) paraoid by #1 (I
originally wrote the code just as you've recommended, FWIW :)), I
realized some would think it's a bit nicer to not have multiple reads
for the same value, and that a shorter variable name would make the
code indentation a bit nicer. This point is admittedly very minor,
but adds a tiny bit of weight to #1.
I think I'd disagree on the indentation, actually. Clarity is always
better in my mind, and it doesn't look like you're in danger of going
past 80 chars. I guess my biggest concern is that I keep reading
absolute value of v instead of level when I see it. Heh. Perhaps
you could even indicate your intent for the variable as described
above by calling it curr_level or something.
The purpose of status_text and secondary_text is different: rather
than set them in each branch of the conditional, or (I think worse,
but IIUC you prefer), do something with it inline in each branch, I
just mutate it in the (few) branches of the conditional as appropriate
and then do something, once, with it.
Am I overlooking some other consideration(s)?
No, not really. You have good points here as well; as I said, I'm not
an authority! I'd let others offer their opinions up on this style.
Clearly you win in maintainability.
+if lvl = 15:
+secondary_text = _('Very little power remaining')
This is probably the correct place to fire off a notification, and
perhaps even badge the icon with a warning badge. Of course, all of
the necessary components aren't in place for this to work perfectly
just yet...not sure if it's worth adding at this point. It would
depend, at a minimum on Eric Burns' forthcoming notification patch for
specifying the appropriate screen corner.
I could add the badge and the notification, sure. Do you want that in
a separate patch? Adding a badge is trivial (you want the
emblem-warning.svg, I guess, not emblem-notification.svg or anything
forthcoming, right?). It'd be a bit quicker if I could do the
notification in a separate patch, I think, as I'm not sure how to do
that yet.
Yeah, I think a separate patch is fine.
+minutes = _('m')
+hours = _('h')
+#TODO: make this less of an wild/educated guess
+minutes_left = int(lvl / 0.59)
+if minutes_left 60:
+guess_text = '%s%s' % (minutes_left, minutes)
+else:
+hours_left = minutes_left / 60
+mins_leftover = minutes_left % 60
+guess_text = '%s%s%s%s' % (hours_left, hours,
+ mins_leftover, minutes)
I think I'd prefer the format 1:23 remaining, without the extra 'h'
and 'm' business.
Ok -- your design had the 3 hours remaining, so I probably shouldn't
have played with your design without asking you first. I'll change it
to just H:mm (as you also request with your code below).
Well, we're talking about 3 different approaches here. I actually do
like the natural language when I see 3 hours remaining or 21
minutes remaining, but 3 hours and 21 minutes remaining gets a bit
long, and I'm not sure it's any more clear than 3:21 remaining
anyway. Plus, in order to do it correctly, you need to handle plurals
and other messiness, so basically I went back on my word (my design)
in light of the actual implementation details.
Also, I'd use a more descriptive variable name like
time_left; guess_text is somewhat ambiguous, apart from the context.
Sure -- I wanted the variable name to scream this code knows that
it's not doing a good job of calculating the time remaining, but of
course it's a very tiny thing to change.
Then compromise with
Re: [PATCH] support battery-charge-state-dependent battery frame icon
On Thu, Apr 17, 2008 at 08:52:16AM -0400, Eben Eliason wrote: [many things] Thanks for the quick reply. All your suggestions / feedback are clear and I'll implement asap and send a new patch. - Eben Martin pgpmBQ3ACMZ2U.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
purpose of ticket
Recently there was a post to this list which I read as saying if you see internal-to-XO situation XYZ, write a ticket and enclose log. [I leapt to the assumption that XYZ ought not to occur.] Well, I saw situation XYZ, and wrote a ticket. But that ticket has been closed. The impression I was left with was we already know that external-to-XO situation UVW can cause the internal-to-XO XYZ. It now appears to me that the reason for asking XYZ to be logged was to triage situation XYZ - in case as-yet-unknown causes led to it. I wish that when the only ticket_mechanism result is information gathering (e.g., from logs), another _resolution_ than 'invalid' were used for closing such a submitted ticket. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TamTam packaging
Hi Jani, On Wed, Apr 16, 2008 at 6:44 PM, Jani Monoses [EMAIL PROTECTED] wrote: The lib is acsound64 not acsound in debian/ubuntu so the link flag needed a change to rebuild the aclient.so instead of using the one in git. the lib will have a 64 if csound was built for double (64 bits) precision. Since the OLPC uses the float build it uses a different file (this setup allows a system to have both floats and doubles version of csound without conflicts). Hardcoded paths starting with /home/olpc were changed too but it still does not play any sound - the graphics are stunning though! :) The version of csound for the XO is a modified version which among other things uses the alsa output module by default. The normal version defaults to portaudio. You would need to check whether csound is actually producing sound on your machine. You can use many of the manual examples (e.g. oscil.csd), which are configured for realtime audio. If csound is producing output tamtam should too. I tried it some time ago on a debian machine, and it worked fine. csound is 5.08.0 do you know if that should be OK? yes, the current version of OLPCsound is a cvs version a little later than the official 5.08, but there should be no important changes. Minor change to get it to build with -Werror with g++ 4.2.3 (Ubuntu 8.04) Can you post the error? Cheers, Andrés ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Developer key
hello, I sent a request to get a developer key for my XO (OLPC) I received the accept but I can't download it with the command wget -p / security http://activation...; http://activation...%22%c2%a0/ listed in the response of the request. Please what can I do? best regards ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] support battery-charge-state-dependent battery frame icon
Eben Eliason wrote: I think that switching to a static very little power remaining at the point at which you do calms some fears. The closer you get to the bottom, the more a little inaccuracy is going to become noticeable. I'll add that I'm going to add a critical state in the EC code. Currently low battery is based on the SOC value (the percentage) and if its wrong you end up with that abrupt low-voltage shutoff with no warning. The voltage output curve in the final stages is very non-linear but there's a threshold that if you are below you have entered into the danger zone and shutoff is imminent. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
version of draft used in the last generation of olpc
hello ; I want to know which version of draft is used in the last generation of olpc. Regards. __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TamTam packaging
Hi Andres, the lib will have a 64 if csound was built for double (64 bits) precision. Since the OLPC uses the float build it uses a different file (this setup allows a system to have both floats and doubles version of csound without conflicts). Changing the makefile to link agains libcsound64.so made it build so that is fine. Are there runtime incompatibilities I should be aware of and which could make it not run on debian? Hardcoded paths starting with /home/olpc were changed too but it still does not play any sound - the graphics are stunning though! :) The version of csound for the XO is a modified version which among other things uses the alsa output module by default. The normal version defaults to portaudio. You would need to check whether csound is actually producing sound on your machine. You can use many of the manual examples (e.g. oscil.csd), which are configured for realtime audio. If csound is producing output tamtam should too. I tried it some time ago on a debian machine, and it worked fine. I tried a while ago and it worked and from pippy as well, but the latest package does not. So it is may not be a tamtam issue after all. csound is 5.08.0 do you know if that should be OK? yes, the current version of OLPCsound is a cvs version a little later than the official 5.08, but there should be no important changes. Minor change to get it to build with -Werror with g++ 4.2.3 (Ubuntu 8.04) Can you post the error? two instances of warning: deprecated conversion from string constant to ‘char*’ which are eliminated by the patch I attached yesterday Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: version of draft used in the last generation of olpc
2008/4/17 wahida mansouri [EMAIL PROTECTED]: hello ; I want to know which version of draft is used in the last generation of olpc. Hi, what do you mean by 'draft'? Can you be more specific? Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TamTam packaging
Hi Jani, On Thu, Apr 17, 2008 at 9:43 AM, Jani Monoses [EMAIL PROTECTED] wrote: Changing the makefile to link agains libcsound64.so made it build so that is fine. Are there runtime incompatibilities I should be aware of and which could make it not run on debian? No incompatbilites as long as all the build is the same precision. I tried a while ago and it worked and from pippy as well, but the latest package does not. So it is may not be a tamtam issue after all. New packages have made into debian testing. You might want to try those. Also remember you need to set the OPCODEDIR (OPCODEDIR64 in your case) so the csound library can find the plugins (plugins in csound include opcode plugins and realtime output modules). Can you post the error? two instances of warning: deprecated conversion from string constant to 'char*' which are eliminated by the patch I attached yesterday Jani Thanks! Cheers, Andrés ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Severe new bug in firmware Q2D13?
I am in Brazil at the moment, without good access to email. But since this seems to be a firmware problem, Mitch Bradley is the right person to help you, at this stage at least. Please check the batteries as Mitch suggests (photos might be helpful for us to see what's going on) and let us know what you find. Mitch, is there anything else which might trigger the Invalid System Date message from OFW? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How do I resart XWindows when running emulation under QEMU
On Thursday 17 Apr 2008 6:43:16 am Steve Lewis wrote: title says is all Crtl-Alt has a special meaning in an emulator and Crtl-Alt-Backspace does not work in either windows or linux. On linux it does some very funky things to the host XWindows See section Restart Sugar in http://wiki.laptop.org/go/Emulating_the_XO/Help_and_tips Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Severe new bug in firmware Q2D13?
C. Scott Ananian wrote: I am in Brazil at the moment, without good access to email. But since this seems to be a firmware problem, Mitch Bradley is the right person to help you, at this stage at least. Please check the batteries as Mitch suggests (photos might be helpful for us to see what's going on) and let us know what you find. Mitch, is there anything else which might trigger the Invalid System Date message from OFW? --scott OFW depends on the date information that it reads from the Real Time Clock chip and has no other source of information. So an Invalid System Date in conjunction with at a very early date means that either the date was never set in the chip or that the chip lost its battery power and thus forgot the date. It is possible that the factory neglected to set the date on some units, but that is less likely than the lost power scenario, because we have already observed two lost power failure modes on multiple units - bad battery holders and defective coin-cell batteries. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
write_file() called when changing Activity name
Is there a way to know whether the write_file() method is called while changing the name of the activity or when closing the activity? I want to delete a file created in the instance folder after closing the activity. I know files in the instance folder are to be deleted automatically, but on sugar-jhbuild they stay (in QEMU the file is deleted when placed in $SUGAR_ACTIVITY_ROOT/instance/ correctly) Regards, Urko ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Severe new bug in firmware Q2D13?
It is possible that the factory neglected to set the date on some units, Isn't if the same that we fixed in some units back in December? http://wiki.laptop.org/go/Fix_Clock ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Severe new bug in firmware Q2D13?
Ricardo Carrano wrote: It is possible that the factory neglected to set the date on some units, Isn't if the same that we fixed in some units back in December? http://wiki.laptop.org/go/Fix_Clock The problem report stated that they are able to activate the machines, but that the activation doesn't persist. Since they can activate, the instructions for using a serial port to recover are unnecessary. With the information that was given in the problem report, it is not possible to determine the root cause of the problem, beyond the fact that the clock does not have the correct time. I am pretty sure that it is not a firmware bug. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: write_file() called when changing Activity name
On Thu, Apr 17, 2008 at 6:27 PM, Urko Fernandez [EMAIL PROTECTED] wrote: Is there a way to know whether the write_file() method is called while changing the name of the activity or when closing the activity? I want to delete a file created in the instance folder after closing the activity. I know files in the instance folder are to be deleted automatically, but on sugar-jhbuild they stay (in QEMU the file is deleted when placed in $SUGAR_ACTIVITY_ROOT/instance/ correctly) You may add a callback that will be executed just before the activity window will be closed: http://www.pygtk.org/pygtk2reference/class-gtkwidget.html#signal-gtkwidget--delete-event Hope that helps, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: write_file() called when changing Activity name
Thanks, I've used the 'destroy' signal in my activity class:
self.connect('destroy', self.__delete_event_cb)
Urko
On Thu, 2008-04-17 at 18:49 +0200, Tomeu Vizoso wrote:
You may add a callback that will be executed just before the activity
window will be closed:
http://www.pygtk.org/pygtk2reference/class-gtkwidget.html#signal-gtkwidget--delete-event
Hope that helps,
Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: How can I set my activity with P_DOCUMENT_RO enable?
If I can write entry in the Journal, can I assume that I have
P_DOCUMENT permission?
How can I retrieve objets from datastore?
My activity uses sqlite to store information, and I read other instances
databases by writing them first on the datastore as sqlite databases:
self.metadata['mime_type'] = 'application/x-sqlite3'
and then querying the datastore for all the sqlite databases on it:
(results, count) =
datastore.find({'mime_type' :'application/x-sqlite3' })
I have no problem to read all the files, but they may be read only.
Hope it helps,
Urko
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Do we ever want to bind more than 8 multicast MAC addresses?
Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How can I set my activity with P_DOCUMENT_RO enable?
The P_DOCUMENT/P_DOCUMENT_RO protections are unimplemented at present. This means that there are no access checks at all in the datastore. For the time being, you can read and write any entries you like. :( Someday, we will add access checks to the datastore and we will teach Rainbow to keep track, for each instance, of which documents the user wants to permit access for. This isn't terribly hard to do well enough for a demo but making it good enough to deploy is beyond my available time for the immediate future. If this subject interests you, feel free to ping me for my thoughts on how to do it (or, even better, to step up with your own patches!) Once access checks and state management are in place, instances will only be able to read DS objects that they are resumed with. They will only be able to write to DS objects that they are resumed with or that they are creating for the first time. It is at this point that P_DOCUMENT and P_DOCUMENT_RO need to be sketched out well enough for continued development. Then, once we get that working, we could reasonably consider whether to deply the DS access checks feature since benign activities would then be less able to screw with the DS if they were subverted. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] support battery-charge-state-dependent battery frame icon
Support battery-charge-state-dependent battery frame icon and upgrade to
consistency with battery icon design from
http://wiki.laptop.org/go/Designs/Frame#06.
Controversially (or so I think), this commit includes a very naive algorithm to
calculate battery time/life remaining, as a principled approach is much more
complex and this approach is better than what a naive human would do (e.g.,
only misleading to those who should be coming up with better patches :)). The
code is very localized and self-contained so it's easy to rip out later.
---
src/view/devices/battery.py | 50 +++
1 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/src/view/devices/battery.py b/src/view/devices/battery.py
index 8a4caf0..6240480 100644
--- a/src/view/devices/battery.py
+++ b/src/view/devices/battery.py
@@ -19,9 +19,11 @@ from gettext import gettext as _
import gtk
from sugar import profile
+from sugar.graphics import style
from sugar.graphics.icon import get_icon_state
from sugar.graphics.tray import TrayIcon
from sugar.graphics.palette import Palette
+from sugar.graphics.xocolor import XoColor
from view.frame.frameinvoker import FrameWidgetInvoker
@@ -37,7 +39,7 @@ class DeviceView(TrayIcon):
xo_color=profile.get_color())
self._model = model
-self.palette = BatteryPalette(_('My Battery life'))
+self.palette = BatteryPalette(_('My Battery'))
self.set_palette(self.palette)
self.palette.props.invoker = FrameWidgetInvoker(self)
self.palette.set_group_id('frame')
@@ -48,21 +50,28 @@ class DeviceView(TrayIcon):
self._update_info()
def _update_info(self):
-name = get_icon_state(_ICON_NAME, self._model.props.level)
-self.icon.props.icon_name = name
+name = _ICON_NAME
+curr_level = self._model.props.level
+xo_color = profile.get_color()
+badge_name = ''
-# Update palette
if self._model.props.charging:
status = _STATUS_CHARGING
-self.icon.props.badge_name = 'emblem-charging'
+name += '-charging'
+xo_color = XoColor('%s,%s' % (style.COLOR_WHITE.get_svg(),
+ style.COLOR_WHITE.get_svg()))
elif self._model.props.discharging:
status = _STATUS_DISCHARGING
-self.icon.props.badge_name = None
+if curr_level = 15:
+badge_name = 'emblem-warning'
else:
status = _STATUS_FULLY_CHARGED
-self.icon.props.badge_name = None
-self.palette.set_level(self._model.props.level)
+self.icon.props.icon_name = get_icon_state(name, curr_level)
+self.icon.props.xo_color = xo_color
+self.icon.props.badge_name = badge_name
+
+self.palette.set_level(curr_level)
self.palette.set_status(status)
def _battery_status_changed_cb(self, pspec, param):
@@ -92,13 +101,26 @@ class BatteryPalette(Palette):
self._progress_bar.set_fraction(fraction)
def set_status(self, status):
-percent_string = ' (%s%%)' % self._level
+curr_level = self._level
+secondary_text = ''
+status_text = '%s%%' % curr_level
if status == _STATUS_CHARGING:
-charge_text = _('Battery charging') + percent_string
+secondary_text = _('Charging')
elif status == _STATUS_DISCHARGING:
-charge_text = _('Battery discharging') + percent_string
-elif status == _STATUS_FULLY_CHARGED:
-charge_text = _('Battery fully charged')
+if curr_level = 15:
+secondary_text = _('Very little power remaining')
+else:
+#TODO: make this less of an wild/educated guess
+minutes_remaining = int(curr_level / 0.59)
+remaining_hourpart = minutes_remaining / 60
+remaining_minpart = minutes_remaining % 60
+secondary_text = _('%(hour)d:%(min).2d remaining'
+ % { 'hour': remaining_hourpart,
+ 'min': remaining_minpart})
+else:
+secondary_text = _('Charged')
+status_text = ''
-self._status_label.set_text(charge_text)
+self.props.secondary_text = secondary_text
+self._status_label.set_text(status_text)
--
1.5.4.1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
It seems a very relevant question. The way collaboration over salut works now (I ask the experts to confirm that), every application will demand a multicast mac address. And four are already taken (01:00:5e:00:00:fb, 01:00:5e:00:00:01, 33:33:00:00:00:01 and 33:33:ff:1:2:3, where 1..3 are the last three bytes of the XO's mac addr). I am assuming this has to be subtracted from the total of 8. So, this would pose a limit of 4 shared applications for a given XO over a simple mesh. Assuming this is correct, than some questions follow. - Is 4 a reasonable limit (is the XO capable of more in terms of processing and memory?) - Is this a hard limit? How hard is to increase this number and what is the compromise? On Thu, Apr 17, 2008 at 5:09 PM, Michael Stone [EMAIL PROTECTED] wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How can I set my activity with P_DOCUMENT_RO enable?
Thanks Michael and Urko for feedback, I have things working between Jam and SynthLab! I have to spread it over all TamTam activities and to clean the code. New bundles coming soon... Olivier Le 08-04-17 à 17:21, Michael Stone a écrit : The P_DOCUMENT/P_DOCUMENT_RO protections are unimplemented at present. This means that there are no access checks at all in the datastore. For the time being, you can read and write any entries you like. :( Someday, we will add access checks to the datastore and we will teach Rainbow to keep track, for each instance, of which documents the user wants to permit access for. This isn't terribly hard to do well enough for a demo but making it good enough to deploy is beyond my available time for the immediate future. If this subject interests you, feel free to ping me for my thoughts on how to do it (or, even better, to step up with your own patches!) Once access checks and state management are in place, instances will only be able to read DS objects that they are resumed with. They will only be able to write to DS objects that they are resumed with or that they are creating for the first time. It is at this point that P_DOCUMENT and P_DOCUMENT_RO need to be sketched out well enough for continued development. Then, once we get that working, we could reasonably consider whether to deply the DS access checks feature since benign activities would then be less able to screw with the DS if they were subverted. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Carrano wrote: | Assuming this is correct, than some questions follow. | - Is 4 a reasonable limit (is the XO capable of more in terms of processing | and memory?) The XO is definitely capable of more, especially for activities like Chat that require minimal CPU/RAM and are usually silent on the network. | - Is this a hard limit? How hard is to increase this number and what is the | compromise? I have an additional question: Could the firmware allow the driver to designate one or more of those slots as a trivial bitwise filter? This would allow the driver to subscribe to one or more ranges of multicast addresses. It would also provide graceful degradation if there are too many multicast addresses to fit: the surplus addresses can just be OR'd together into a filter. There will be some false positives that will have to be screened out by the driver, but perhaps not too many. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB9GAUJT6e6HFtqQRAu8kAKCXPHKqWLm5Rk2pimt8+yg3sW/VKgCfTTjn eqzgVrWnAxfJ9wmOvkbMWzI= =h0XZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
I have a feeling that the capability of participating in up to four activities over a simple mesh scenario (no school server present) seems good enough. But I may be wrong and we certainly don't have enough (if any) user input to validate this (or not). On Thu, Apr 17, 2008 at 6:38 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Carrano wrote: | Assuming this is correct, than some questions follow. | - Is 4 a reasonable limit (is the XO capable of more in terms of processing | and memory?) The XO is definitely capable of more, especially for activities like Chat that require minimal CPU/RAM and are usually silent on the network. | - Is this a hard limit? How hard is to increase this number and what is the | compromise? I have an additional question: Could the firmware allow the driver to designate one or more of those slots as a trivial bitwise filter? This would allow the driver to subscribe to one or more ranges of multicast addresses. It would also provide graceful degradation if there are too many multicast addresses to fit: the surplus addresses can just be OR'd together into a filter. There will be some false positives that will have to be screened out by the driver, but perhaps not too many. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB9GAUJT6e6HFtqQRAu8kAKCXPHKqWLm5Rk2pimt8+yg3sW/VKgCfTTjn eqzgVrWnAxfJ9wmOvkbMWzI= =h0XZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer key
On 17.04.2008, at 15:56, Daly Ikbel wrote: hello, I sent a request to get a developer key for my XO (OLPC) I received the accept but I can't download it with the command wget -p / security http://activation...; listed in the response of the request. There is no space after the slash, it is wget -p /security This names a path on your system (/security). - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
Yes, this is a problem for us. We need to request that 16 be allocated. wad On Apr 17, 2008, at 5:09 PM, Michael Stone wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Mesh connectivity from regular WiFi gear (Martin Langhoff)
Hi All, FYI I don't know what is supposed to work but they have tested a bunch in Nepal. I believe that a DLINK DWL2100AP was the first choice in Nepal. Looks like they last tested Lantech WL54G BR with pretty good results. See: http://blog.olenepal.org/ latest post. You may want to check with Bryan, Sulochan or Dev Mohanty ([EMAIL PROTECTED]) for the final word. I added DLINK DWL2100AP to the wiki link below. Initially Bryan recommended a DLINK DWL2100AP to the people in Cambodia. I'm not sure what they ended up with but you can try pinging them too. Main contact there was: matt wolstencroft [EMAIL PROTECTED] I think the Cambodia discussion was logged under RT ticket: 8321 although I can't seem to access RT right now to confirm. There was discussion of openWRT firmware, lazyWDS and other gritty details on that thread with Michail Bletsas providing the input from OLPC. HTHs. Greg S Message: 6 Date: Thu, 17 Apr 2008 09:32:59 -0400 From: Walter Bender [EMAIL PROTECTED] Subject: Re: [Server-devel] Mesh connectivity from regular WiFi gear To: Martin Langhoff [EMAIL PROTECTED] Cc: server-devel server-devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Also, do we have wikipage of tested APs? http://wiki.laptop.org/go/Wireless_Access_Point_Compatibility This page just reports results for standard use, not in the context of a school-server scenario, which would merit additional testing. -walter ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Mesh connectivity from regular WiFi gear
I thought there might be a wireless driver piece that needed to be addressed. I gave the PEAP trac item to Michail for comment. Thanks, Kim On Thu, Apr 17, 2008 at 1:51 PM, Marten Vijn [EMAIL PROTECTED] wrote: On Thu, 2008-04-17 at 09:27 -0400, Kim Quirk wrote: Martin, Wad, We have promised to provide NYC with a schedule for the item you mention, Martin, trac #6855, as well as support for PEAP. trac #6900. I have told them that PEAP was a 2009 feature (mainly because I wanted to discourage them), but they have asked if we can pull it in. Considering: http://www.freebsd.org/doc/en/books/handbook/network-wireless.html and http://www.freebsdmall.com/% 7Eloader/en_US.ISO8859-1/articles/wireless/article.htmlhttp://www.freebsdmall.com/%7Eloader/en_US.ISO8859-1/articles/wireless/article.html This would be possible and I am willing to put time in this. If needed, I could put some effort to put it in firmware (tinybsd) for any i386 mobo/embedded system. The XS could to radius (and optinally config AP's with ssh/or/puppet) Marten So the next step on these two items is to figure out the development and test effort associated with these two features. It would be great if people could add their thoughts into those trac bugs as to what work is needed. After we have that, we can weigh that against other priorities and come up with which release to put these in. Thanks, Kim On Thu, Apr 17, 2008 at 8:58 AM, Martin Langhoff [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 3:26 AM, John Watlington [EMAIL PROTECTED] wrote: If a school is using a mesh, we have a carefully designed system to ensure that a laptop doesn't go into simple mesh mode, and instead connects automatically with the school. If a school is using traditional WiFi, there is no such guarantee. This is possibly bad, as kids that aren't associated can interfere with those that are. When at NYC, you mentioned that the NM searches and prefers the school-mesh-n essids of mesh-type signals. And that perhaps we could make it lock into infrastructure-mode essids of that name with the same kind of preference. Would this simple fix help sort the problem out? Also, do we have wikipage of tested APs? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- Marten Vijn http://martenvijn.nl http://wifisoft.org http://opencommunitycamp.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] introduction...
At the moment I believe coping with fedora, would probably be more difficult than doing what you say you are already going go to do anyway. Why not let me start working on porting to debian, I will not be Nepal until June/July so have plenty of time. I believe, porting said packages to debian and running ebox is going to be easier than just looking at one of the existing builds, which might give me an idea of what XS does, but won't contribute in any way. David On Mon, Apr 14, 2008 at 2:03 AM, Martin Langhoff [EMAIL PROTECTED] wrote: Welcome David! please use the XS images we are working on now, which are based on Fedora. We are exploring a Debian move, and your experience will be welcome there, but at the moment using Debian for the base of the XS will mean that you will have to package independently - the kernel with custom drivers/patches - ejabberd - idmgr - a lot of configuration settings We will package all of those in .debs soon, but it is a ton of complex work for you if you want to do it on your own. Try build 161 or 162, cope a bit with Fedora, and be part of the wider project here... cheers, martin 2008/4/11 David Van Assche [EMAIL PROTECTED]: Hi, I have recently applied for a volunteer position at OLE in Nepal, and it was suggested I introduce myself here. So here goes. I have been involved in the Linux community for a while, but my experience lies very much in the Debian/Ubuntu field, which I feel is far friendlier and more logical than the other distros. I have run my own IT company for 5 years, where we built bespoke programs, but mostly web solutions and administering accounts. Since then I administered a medium sized school, building the entire system based on LTSP (an amazing system) which really allows for the administration side to be a non-headache. I also taught IT for a year at this school. I've been following the list a little and I've taken a look at sugar which is very intriguing, though obviously very young still. I've been talking to Bryan Berry from OLENepal, and suggested installing a prototype XS server based on ebox with ubuntu or debian under the hood. The main reason is my knowledge in this area and the fact that I'll need to teach this to other sysadmins/teachers in Nepal. I know you guys have some ideas already, and you've already started on something, and I wouldn't want to just branch without synchronizing with the XS devel team. There are many aspects of the mesh networking aspect that I'm not to clear about, as I've never worked with this, though it seems pretty clear. I have always worked with webmin with my ltsp system without any problems, though I know how developers feel about its security and its internal workings, but lets be clear here, we're working with schools, not banks so I don't see the fuss. Anyway, I do think ebox is a good full solution that would do a better job than webmin in terms of security, and would be easily understood by most admins... With your blessign, I'd like to go ahead and build a prototype based on debian or Ubuntu for Nepal... with whatever help is needed from the XS devel team. Kind Regards, David Van Assche ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
