Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
Simon McVittie wrote: PS makes an unlimited number of connection attempts, with a short delay between each one (we should probably change this to use an exponential backoff process so the delays get longer as you're offline for longer, up to a maximum of perhaps 10 minutes). #2522. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote: Using standard directories is not scribbling all over the filesystem! This anti-compatibility attitude needs to stop. It's really hurting OLPC, needlessly making the goals harder to achieve. Breaking compatibility is something to be done as a last resort, when no alterative will work. For better or for worse, compatibility has been broken, and on a level as fundamental as file access. If an application can't even access the user's files without being aware of the datastore, what good is it to pretend that providing small bits of backwards compatibility will make things substantially easier? For us, $SAR/tmp lives in RAM and is severely limited (maybe to as little as 1MB per application). $SAR/instance is used for transient per-instance disk-backed storage. Since it's a given that work needs to be done to port applications to Sugar, it's a _good_ thing that a programmer is also confronted with the decision as to which of these two temporary directories to use. Enabling a wrapper for /tmp would have us make that decision for them, and as fellow Python programmers know: explicit is better than implicit, and in the face of ambiguity, refuse the temptation to guess. The long-term goal should be to support solid sandboxing of true all-over-the-filesystem software installs. This may need a unionfs filesystem so that files can be put everywhere without the dummy files needed for file-on-file bind mounts. Imagine if you could install any RPM, knowing that it had no way to corrupt your OS. That goal is not something I'm spending much time thinking about. The level of protection provided by Bitfrost is not something you can do without serious compatibility breaks with how things are done at present. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Nov 2007 at 17:49:52 -0500, Eben Eliason wrote: Just a mention, since this thread is getting a lot of attention. There is an added visual element which should be in play here, according to the design. There should be an intermediate state before XOs disappear from the view, as outlined in: http://dev.laptop.org/ticket/3657 As outlined in that bug, this has nothing to do with the Telepathy backends and PS, it's just a layout/presentation tweak in the Sugar shell (and indeed, the bug is assigned to sugar, not presence-service). Getting more information from the network, via Telepathy and PS, to the shell would be necessary to take it beyond what you suggest in comment#2, but is not feasible in the short term (i.e. Update.1). Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHMukAWSc8zVUw7HYRAtF/AKDlmpJsI08JeWrYlebdtGHovF4oSgCfeEAV ZIXr8UwO6guqBRbkbvlVivw= =dRfa -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Nov 2007 at 13:36:45 -0500, Giannis Galanis wrote: I can definitely try to arrange this. But, can you please send me the tarball to test it in the mean time? Will do. I don't think it's feasible to implement correct handling of PS restarts in sugar.presence for Update.1, so unless the release engineering team specifically tell me to, I won't be addressing that bug until a later release. Ok, i will reassign the bug to presenceservice. As long as restarting sugar works, we can stick to that for now. No, it's not a Presence Service bug, it's a Sugar bug (the sugar.presence module is part of Sugar, and it's that module that will have to be changed). Please assign to component Sugar, with owner smcv or morgs, and keep the 'collaboration' keyword (we use that to keep track of collaboration-related bugs in other people's components). $getent hosts jabber.laptop.org 2001:4830:2446:ff00:201:6cff:fe07:68ec jabber.laptop.org - frequent reply 18.85.46.41 jabber.laptop.org --rare reply $ping jabber.laptop.org PING jabber.laptop.org (18.85.46.41) 56(84) bytes of data. 64 bytes from jabber.laptop.org (18.85.46.41): icmp_seq=1 ttl=63 time= 67.4 ms ... $telnet jabber.laptop.org 5222 blabla... connected hello replied with an xml packet with xml-not-well-formed included so it seems that it is a PS issue. Perhaps it is not waiting long enough, or doesnt make enough tries when trying to connect. I have reassigned the bug to presenceservice. Was all this done on a machine exhibiting the failure you mention? PS makes an unlimited number of connection attempts, with a short delay between each one (we should probably change this to use an exponential backoff process so the delays get longer as you're offline for longer, up to a maximum of perhaps 10 minutes). What I meant here is, Does the PS check if jabber server is accessible, and then runs telepathy-gabble?, or this is one of the tasks of telepathy-gabble?, which as I see you replied to Like I said, the PS doesn't check whether the server is accessible, it just optimistically tries to connect anyway. I believe this is the right thing to do. have you tried to check connecting to gabble with the laptops available there? Does it work fine? Not recently with XOs, I must admit (downloading filesystem images takes a while) but it's always worked fine from my jhbuild. Perhaps you can connect to an XO here with ssh, and debug real time what is exactly happening. Talk to me on #sugar when you have an Internet-accessible XO that's exhibiting this problem. I'm smcv on IRC. it was suggested (i think bug 4700) that it is possible that the jabber server might have a limit in number of users. Is this possible? It's possible, but it's always worked for me... Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHMtxBWSc8zVUw7HYRAj3fAJ95oDyvE30EXR3UP4/muZdWtbAE3ACggXbS EEhhwpa+vAW+7uwvuIMkK/g= =uOn0 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: secure /tmp and /var/tmp
On Nov 8, 2007, at 16:51 , Jim Gettys wrote: I sympathize with Albert's point here: we should be no more incompatible than we have to be... Just because we have to break some things, doesn't mean we have to break everything. - Jim +1 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] [sugar] secure /tmp and /var/tmp
I sympathize with Albert's point here: we should be no more incompatible than we have to be... Just because we have to break some things, doesn't mean we have to break everything. - Jim On Thu, 2007-11-08 at 10:42 -0500, Albert Cahalan wrote: On 11/8/07, Ivan Krstić [EMAIL PROTECTED] wrote: On Nov 7, 2007, at 9:09 PM, Albert Cahalan wrote: Using standard directories is not scribbling all over the filesystem! This anti-compatibility attitude needs to stop. It's really hurting OLPC, needlessly making the goals harder to achieve. Breaking compatibility is something to be done as a last resort, when no alterative will work. For better or for worse, compatibility has been broken, and on a level as fundamental as file access. If an application can't even access the user's files without being aware of the datastore, what good is it to pretend that providing small bits of backwards compatibility will make things substantially easier? One failure is no excuse to purposely fail in every way. Not every application even needs access to a user's files. The datastore has changed and apparantly will change. Perhaps it can someday be less awkward to deal with. In any case, yes, it is extra work and ugly code. You're affecting every porting effort; it must be easy to make that decision when it's somebody else's code base getting screwed with #ifdef everywhere. For us, $SAR/tmp lives in RAM and is severely limited (maybe to as little as 1MB per application). $SAR/instance is used for transient per-instance disk-backed storage. Since it's a given that work needs to be done to port applications to Sugar, it's a _good_ thing that a programmer is also confronted with the decision as to which of these two temporary directories to use. Enabling a wrapper for /tmp would have us make that decision for them, and as fellow Python programmers know: explicit is better than implicit, and in the face of ambiguity, refuse the temptation to guess. This is nothing new. It's been standard on SunOS for ages. The /tmp directory is in RAM, and /var/tmp is on disk. You are not so special that you need to break everything. AFAIK, this is even a common (normal?) setup on BSD. BTW, if you're going to keep calling it $SAR, then you'd better make that the real name of the variable. The long-term goal should be to support solid sandboxing of true all-over-the-filesystem software installs. This may need a unionfs filesystem so that files can be put everywhere without the dummy files needed for file-on-file bind mounts. Imagine if you could install any RPM, knowing that it had no way to corrupt your OS. That goal is not something I'm spending much time thinking about. The level of protection provided by Bitfrost is not something you can do without serious compatibility breaks with how things are done at present. If you don't solve it, people will just turn Bitfrost off. ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007, at 10:42 AM, Albert Cahalan wrote: One failure is no excuse to purposely fail in every way. It's not a purposeful failure. We're imposing non-obvious changes on semantics due to restrictions in our environment, such as a strict limitation on the size of /tmp. I'd _much_ rather have my application break during porting when I try to write to /tmp, at which point I go and think about where it should be writing instead, than to have it explode in strange ways when further writes to /tmp start erroring out because the (small amount of) space has been exhausted. If I'm in the minority with this sentiment, I am open to revising the policy. This is nothing new. It's been standard on SunOS for ages. The /tmp directory is in RAM, and /var/tmp is on disk. A tiny size restriction is pretty new. You are not so special that you need to break everything. I am a uniquely special snowflake of unique specialness. If you don't solve it, people will just turn Bitfrost off. Bitfrost is not a general Linux distribution security mechanism. Sugar is not a general Linux desktop environment. These things are designed with different goals in mind, for a different purpose, and behave differently than the things you're used to. You can argue that our designs are wrong and the behaviors broken, but even that's for the most part orthogonal to the argument that the designs should be such that everything old continues to magically work. Backwards compatibility, quite simply, was not an OLPC design goal, and while I am happy to not deviate from old behavior superfluously, I also have an interest in doing the right thing for the new platform, especially when dealing with ambiguity. At the moment, I regard the /tmp situation as ambiguous and misleading. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007 5:20 PM, Ivan Krstić [EMAIL PROTECTED] wrote: Bitfrost is not a general Linux distribution security mechanism. Sugar is not a general Linux desktop environment. These things are designed with different goals in mind, for a different purpose, and behave differently than the things you're used to. You can argue that our designs are wrong and the behaviors broken, but even that's for the most part orthogonal to the argument that the designs should be such that everything old continues to magically work. Backwards compatibility, quite simply, was not an OLPC design goal, and while I am happy to not deviate from old behavior superfluously, I also have an interest in doing the right thing for the new platform, especially when dealing with ambiguity. At the moment, I regard the /tmp situation as ambiguous and misleading. +1. On the Sugar side we asked our UI design team to come up with a completely new design. If the goal was compatibility we should have started from the existing (the GNOME desktop, for example) and evolved it gradually towards our vision. We have reused existing libraries as much as possible (gtk, cairo, matchbox, mozilla, telepathy just to cite a few) which is essential to be able to base our activities on existing software. Write, Browse, Read, and the whole collaboration support, are the proof of how well this worked in practice. With very little python code we have achieved both integration with the system and reuse of existing code. Though applications backwards compatibility just doesn't make sense in this context. We consciously broke it with the high level design, both of the user experience and of the security framework. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007, at 18:09 , Marco Pesenti Gritti wrote: Though applications backwards compatibility just doesn't make sense in this context. We consciously broke it with the high level design, both of the user experience and of the security framework. That's not the point. The point is how hard we make it for people to port their apps to Sugar. And in my opinion we should not make it unnecessarily hard. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Thu, 2007-11-08 at 18:11 +0100, Bert Freudenberg wrote: On Nov 8, 2007, at 18:09 , Marco Pesenti Gritti wrote: Though applications backwards compatibility just doesn't make sense in this context. We consciously broke it with the high level design, both of the user experience and of the security framework. That's not the point. The point is how hard we make it for people to port their apps to Sugar. And in my opinion we should not make it unnecessarily hard. I think that by not reusing names for things that are different and making ambiguous situations being resolved by explicit actions, is precisely making easier the porting of apps to Sugar. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007, at 11:33 AM, Jim Gettys wrote: Heh. You are way too young It takes a long time to become young! On the upside, my work did not give rise to xorg.conf ;) Marcus Leech wrote: My first Unix machine had 128K of MOS memory, and we supported about 10-15 interactive users on it MOS memory? _MOS memory_? In my young day we started out as apprentice binary registers. Six o'clock in the morning, come rain, sleet, hail, or snow, we'ed be there kicking each other in the buttocks -- right for 1, left for zero. A'course I say registers, cause they were registers to us. But it were a stack really. None o' this modern stack pointer rubbish, either. You used to 'ave to remember which were t'top element in yer 'ead. Anyway, due to vocal support, we'll preserve /tmp. I don't think it's the best course of action, but we'll roll with it. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On 11/8/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: In some cases though it's better to break than to keep a fake compatibility with something which is designed for a different use case. That way the error is explicit and the activity author knows it needs to be fixed. And I agree with Ivan that this is the case for /tmp. The XO /tmp is **exactly** like a SunOS /tmp. It's in RAM. Well, one difference: it was common to have only 8 MB. There is nothing new here. The XO is not special. Understand that each and every #ifdef is a despised wart that makes code less maintainable. I know it isn't YOUR code. Please be considerate of other people's code. BTW, it's not as if running out of RAM will fail to alert the author. There is no problem here. One can just as well have trouble with malloc or severe recursion. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Thu, 2007-11-08 at 11:20 -0500, Ivan Krstić wrote: A tiny size restriction is pretty new. Heh. You are way too young The presumption has always been you'd better keep things in /tmp pretty small; that's why the distinction between /tmp and /var/tmp was made. It allowed people to use RAM file systems for speed long before it would have otherwise been feasible. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] secure /tmp and /var/tmp
On Nov 8, 2007 6:11 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: On Nov 8, 2007, at 18:09 , Marco Pesenti Gritti wrote: Though applications backwards compatibility just doesn't make sense in this context. We consciously broke it with the high level design, both of the user experience and of the security framework. That's not the point. The point is how hard we make it for people to port their apps to Sugar. And in my opinion we should not make it unnecessarily hard. I agree that is some cases Sugar make it *unnecessarily* hard. We fixed many of these and we will continue to improve in this respect. In some cases though it's better to break than to keep a fake compatibility with something which is designed for a different use case. That way the error is explicit and the activity author knows it needs to be fixed. And I agree with Ivan that this is the case for /tmp. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Micropolis project: git hosting application
1. Project name : Micropolis
2. Existing website, if any : none yet
3. One-line description : GPL city-construction game
4. Longer description : Micropolis lets you design and build your own
: city, in classic constructionist fashion. It's
: written in C with TCL and Python, and is being
: ported to Sugar with the TCL gradually gone.
5. URLs of similar projects :
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URLE-mail
- --
#1 dhopkins Don Hopkins [EMAIL PROTECTED]
#2 gnuJohn Gilmore [EMAIL PROTECTED]
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
main tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[X] A separate mailing list, projectname-git, should be created for commit
notifications
[ ] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Notes/comments:
John Gilmore SSH2 key:
ssh-rsa
B3NzaC1yc2EBIwAAAi8AoLBncnMXZTJPUoIr1Rfc+sM0dKd8Qbwoidw3F+Fqq8jNRqFOe7u1WpoiRe4yj18V5LO7GUxSwThgQI8tWyoVvDu7/5visOxzG7aDfu9CMysoLkR9PlNg1JbsP4yl1zyLze18VmofJbprTv1gCAhAue7S1dItC6FXipzFVF2e9In+E5NJQoM2EJUGLcrnRuz76ebfgl7Z1JZH5ryO0+vlLsnW+iSpHMhM0pWLI2tJ6ws/ArxnXon6CenX+OU0ZdsRMEJejqGgPf7rJHqEQv/FEfWQOafjeSxePMNf3pWlDa5FC5aFspFDhqiQxUlMc+f40sYR8krhbjyNiE6N1T8D5x+HFtaKmNy6gizEl+l00ciJMFpRCBIL7jzEhQ5LYzoP6Ic4U+xriZBDjJHWyIzmjCohBgqy+FLkqMj7v1Uli5nujrxsZuD+nWnnbQNVn1+C2IDHCw2kgLcg/sq8YXj+m4LdmGIb8s3uydc7Kk3dmnTXvCgdi1KP23HpHa8zsvnerhDI6Nyz4Gli4Za0llNgD+Ey8r3Eqx8W0e/DZwTbSIW5zSWByHoGSGUiWO26MEoIN8L8TbX7+zPhXoiVDBBpnsRQmirUL5xwsWc6ZWasMPx/WGqudlvmtkoJxnpDdW63qPqNa6zEOvMR7gVp/EWBCP3vVvB84UKtPNIPEnPvsytrFbC0KyOWh2l6lejKfZHYGuZBxFXnyMBLwpVpxSdHcooWkSYSdMPipvQoG09B
[EMAIL PROTECTED]
Don Hopkins SSH2 key is forthcoming. (If you add me now, can I add him later?)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
SimCity project: git hosting application
1. Project name : SimCity
2. Existing website, if any : none yet
3. One-line description : EA-licensed GPL city-construction game
4. Longer description : SimCity lets you design and build your own
: city, in classic constructionist fashion.
: EA will do quality assurance testing on this
: version, for use with the SimCity trademark.
5. URLs of similar projects : Micropolis
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URLE-mail
- --
#1 dhopkins Don Hopkins [EMAIL PROTECTED]
#2 gnuJohn Gilmore [EMAIL PROTECTED]
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be familiar to
CVS and Subversion users, and that tends to work well for most projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
main tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the list
we chose to create above
[X] A separate mailing list, projectname-git, should be created for commit
notifications
[ ] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Notes/comments:
John Gilmore SSH2 key:
ssh-rsa
B3NzaC1yc2EBIwAAAi8AoLBncnMXZTJPUoIr1Rfc+sM0dKd8Qbwoidw3F+Fqq8jNRqFOe7u1WpoiRe4yj18V5LO7GUxSwThgQI8tWyoVvDu7/5visOxzG7aDfu9CMysoLkR9PlNg1JbsP4yl1zyLze18VmofJbprTv1gCAhAue7S1dItC6FXipzFVF2e9In+E5NJQoM2EJUGLcrnRuz76ebfgl7Z1JZH5ryO0+vlLsnW+iSpHMhM0pWLI2tJ6ws/ArxnXon6CenX+OU0ZdsRMEJejqGgPf7rJHqEQv/FEfWQOafjeSxePMNf3pWlDa5FC5aFspFDhqiQxUlMc+f40sYR8krhbjyNiE6N1T8D5x+HFtaKmNy6gizEl+l00ciJMFpRCBIL7jzEhQ5LYzoP6Ic4U+xriZBDjJHWyIzmjCohBgqy+FLkqMj7v1Uli5nujrxsZuD+nWnnbQNVn1+C2IDHCw2kgLcg/sq8YXj+m4LdmGIb8s3uydc7Kk3dmnTXvCgdi1KP23HpHa8zsvnerhDI6Nyz4Gli4Za0llNgD+Ey8r3Eqx8W0e/DZwTbSIW5zSWByHoGSGUiWO26MEoIN8L8TbX7+zPhXoiVDBBpnsRQmirUL5xwsWc6ZWasMPx/WGqudlvmtkoJxnpDdW63qPqNa6zEOvMR7gVp/EWBCP3vVvB84UKtPNIPEnPvsytrFbC0KyOWh2l6lejKfZHYGuZBxFXnyMBLwpVpxSdHcooWkSYSdMPipvQoG09B
[EMAIL PROTECTED]
Don Hopkins SSH2 key is forthcoming. (If you add me now, can I add him later?)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
