Re: Updated glibc-2.7 for geode
Rob Savoye wrote:
>The geode patch must be in sysdeps/i386/i686, not in i585. For the
> Geode support, it only configures correctly if the geode sub directory
> is in the i686 directory.
Ok, I got the 2.7 packages to build:
http://www.codewiz.org/pub/glibc-geode-2.7/
These can replace the older glibc-2.6.90-19 after performing the
usual tmpfs dance:
mount -t tmpfs none /usr/lib/locale
rpm -U --ignorearch glibc-2.7-2.geode.rpm glibc-common-2.7-2.i386.rpm
mv /usr/lib/locale/locale-archive /
umount /usr/lib/locale
mv /locale-archive /usr/lib/locale
{one of these days we need to teach build-locale-archive to fall
back to read()/write() whenever mmap() fails}
The system boots normally and I didn't measure a relevant
change in boot time.
Now it would be a good time to perform some application
benchmarking. Feedback welcome.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Gerard, > I am properly admonished and shall hold my performance speculations > until my machines arrive. I just wanted to mention that it is not conceivable. (I even took a picture but forgot to put a link: http://dev.laptop.org/~yoshiki/pictures/pict0425.jpg ) The performance is probably a less-challenging issue. Giving flexibility to developers and users while proctecting an activity from others is another thing. I thought using another activity as a library in yours in the same address space was something the security people would like to avoid. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New ship.2 build 649
On Nov 30, 2007 5:30 PM, Build Announcer Script <[EMAIL PROTECTED]> wrote: > http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build649/ This is now our ship.2 candidate. http://download.laptop.org/xo-1/os/official/649/jffs2/ Library cleanups and a Record fix. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New ship.2 build 649
http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build649/ -Record-40.xo +Record-44.xo --- Record-44 --- * #5230 further fix -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
--- Yoshiki Ohshima wrote: Great! but sorry for my ignorance but what "a signed copy" means? Shall we test it on our (B4) laptops? Or it'll make it hard for future update? http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ is the same thing but "unsigned"? -- Yoshiki --- end of quote --- Signed means that it will work on a write protected machine. If you're laptop is not write protected, the unsigned version will work exactly the same. - AlexL ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
> A signed copy of build 648, which is our ship.2 release candidate, is now at: > http://download.laptop.org/xo-1/os/official/648/jffs2/ > This build contains firmware q2d05, available separately at: > http://dev.laptop.org/pub/firmware/q2d05/ Great! but sorry for my ignorance but what "a signed copy" means? Shall we test it on our (B4) laptops? Or it'll make it hard for future update? http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ is the same thing but "unsigned"? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Thank you, Mike, > That said, activities which use the high-level components only might be > able to be ported just by rewriting the Sugar APIs with a Win32 > compatibility layer a port of Telepathy and a bit of bailing wire. That > might let children communicate and access the materials... but that > would be a fairly involved project, and I don't know if we'd find all > that many Win32 developers interested in attempting it. That would be useful for longer term. TamTam on Windows would be cool so you can jam with a Windows user over the net, for example. > > And, I see that one of the biggest downside of our software is that > > kids cannot participate the software development effort from their > > laptops (except...). If we are to look at different platforms, it is > > nice to think about easy support of on-laptop-development. I don't > > care if it is on Windows or Mac OS; on top of Windows (or Mac OS), you > > as an end-user can still do a lot. (Basically the same argument in > > "filtered Internet access is better than no Internet access".) > > > Yes, we really need to get "Develop" development un-stuck. We currently > have only Pippy (which doesn't do files) and the Squeak IDE available > on-machine. We need that full Python IDE available for the children > ASAP. After all, we've got a whole key on the keyboard devoted to it. > Even if the IDE is just file-open/close/create, file-tabs and syntax > highlighting it would be sufficient to start programming on-machine. Yes. Maybe a Python IDE in Squeak is not a so bad idea. At some time soon, somebody in Etoys/Smalltalk community need to write up how to start Smalltalk programming on XO, such as making writable copies of etoys.image and etoys.changes to a directory and turn "eToyFriendly" preference off, etc. (Ah, that is almost it^^;) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Signed 648 (ship.2 release candidate)
A signed copy of build 648, which is our ship.2 release candidate, is now at: http://download.laptop.org/xo-1/os/official/648/jffs2/ This build contains firmware q2d05, available separately at: http://dev.laptop.org/pub/firmware/q2d05/ --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
> >> This, I do believe is probably a fantastic thing to work on. What we > >> really need in cases like this is, as you say, a chat widget that is > >> based on the chat activity, having the same look, feel, options, etc. > >> Just as we have an Abiword widget for text which can be used anywhere > >> we should adopt a standard chat widget that can be designed and > >> maintained by OLPC, so that the experience is always consistent and > >> any fixes or improvements are automatically seen within any activity > >> that makes use of it. > >> > >> Do those working on Chat see this as a viable possibility? > >> > > > > I don't see any reason why not. > > > > Do you envision this as something that might be enabled in every activity > > automatically, or something that each activity would integrate manually? The > > former might mean that the chatting UI would be more consistent, but perhaps > > allows for less flexibility in integrating with different styles of activity > > UI. > > > > (Shared activities are built on top of chat rooms, so there's already a way > > for all the participants to send messages to each other.) > > > > > I am all for the manually adopted widget. I think Eben has pointed out > problems with the every activity model. But in any case, the widget is a > natural first step to any further functionality. To clarify my point, I'm arguing that we should absolutely have a generic "every-activity" model that exists "on top of" the activity in some manner. I'm also arguing that, in the cases where chat is desired as an integrated part of the main activity interface, we offer a consistent widget for activity authors to embed at any size and position they choose. My presumption is that most activities won't actually need to embed the chat element, but it seems nice to offer a simple way to do so when the desire is there. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Dafydd Harries wrote: > Ar 30/11/2007 am 10:25, ysgrifennodd Eben Eliason: > >>> I have been reviewing the code in the chat application and given the >>> abilities of the dbus do not feel that text messages will add all that >>> much complexity to the application. My original query was not as much >>> having a chat window in my activity but more of a Delphi like component >>> that I could drop into the buddy panel weld into my existing tubes and >>> be done with chat. >>> >> This, I do believe is probably a fantastic thing to work on. What we >> really need in cases like this is, as you say, a chat widget that is >> based on the chat activity, having the same look, feel, options, etc. >> Just as we have an Abiword widget for text which can be used anywhere >> we should adopt a standard chat widget that can be designed and >> maintained by OLPC, so that the experience is always consistent and >> any fixes or improvements are automatically seen within any activity >> that makes use of it. >> >> Do those working on Chat see this as a viable possibility? >> > > I don't see any reason why not. > > Do you envision this as something that might be enabled in every activity > automatically, or something that each activity would integrate manually? The > former might mean that the chatting UI would be more consistent, but perhaps > allows for less flexibility in integrating with different styles of activity > UI. > > (Shared activities are built on top of chat rooms, so there's already a way > for all the participants to send messages to each other.) > > I am all for the manually adopted widget. I think Eben has pointed out problems with the every activity model. But in any case, the widget is a natural first step to any further functionality. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Ar 30/11/2007 am 10:25, ysgrifennodd Eben Eliason: > > I have been reviewing the code in the chat application and given the > > abilities of the dbus do not feel that text messages will add all that > > much complexity to the application. My original query was not as much > > having a chat window in my activity but more of a Delphi like component > > that I could drop into the buddy panel weld into my existing tubes and > > be done with chat. > > This, I do believe is probably a fantastic thing to work on. What we > really need in cases like this is, as you say, a chat widget that is > based on the chat activity, having the same look, feel, options, etc. > Just as we have an Abiword widget for text which can be used anywhere > we should adopt a standard chat widget that can be designed and > maintained by OLPC, so that the experience is always consistent and > any fixes or improvements are automatically seen within any activity > that makes use of it. > > Do those working on Chat see this as a viable possibility? I don't see any reason why not. Do you envision this as something that might be enabled in every activity automatically, or something that each activity would integrate manually? The former might mean that the chatting UI would be more consistent, but perhaps allows for less flexibility in integrating with different styles of activity UI. (Shared activities are built on top of chat rooms, so there's already a way for all the participants to send messages to each other.) -- Dafydd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Yoshiki Ohshima wrote: > Well, I know that I can make a user document with a running movie > clip, real time view-finder of camera, spectrum analysis of audio > input, and a user-scripted simulation going at the same time > on B4 (4-5 fps is not so great though). > > These widgets are running in the same address space but that is > offset by some facts such as Etoys display model is not optimal, our > code for playing movie, copying bits of video frames to make the > player a real end-user scriptable object, FFT are not optimized, etc. > It should be possible to provide an ok experience for most of the time > and I was not talking unrealistic rant, I believe. > > -- Yoshiki > ___ > Yoshiki, I am properly admonished and shall hold my performance speculations until my machines arrive. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
linkchecker script
Hey! I've just written a simple linkchecker script in python, and thought someone could perhaps use it. It recurses through the links of a given domain and stays inside that domain. For found links it gives you the feedbacks: ok, outside, 404, https http://wiki.laptop.org/go/Linkchecker.py Regards, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
> I would like to see the OLPC retain its non-windowed presentation style. > I have run into people that have no idea how many windows are running. > When they do not see the browser, they simply start another one, > ignoring Z order and minimized applications. Don't laugh, my wife and I > are the ISP for our condo complex and we have a few service calls along > these lines. Given the OLPC environment, fixed frames and whole screen > activity switching makes a lot of sense. So if I am performing an > activity that does not require chat and wish to reference a colleague on > line, hitting F3 and choosing the chat application is not offensive at all. Agreed. We aim to implement some really nice forms of activity switching as well. > For those activities that require chat, the interaction should happen in > the context of the application's display structure. I am lucky that my > particular application is square, this lends the rest of the rectangle > to the buddy panel, which has the list of the participants in the upper > half with the lower half containing the chat window. I am just finishing > the basic game communications and will be moving on to the game player > negotiation and setups this weekend. I am resisting tabbing the tool > bar for these tasks if at all possible to prevent my square Go board > from getting any smaller. I really think that the toolbar should be tabbed, actually, despite the loss of those 45px. You really should have some basic controls like "new game", perhaps "undo/redo move", a board size selector, etc. Having all of these basic games controls neatly laid out along the top of the screen would be quite appropriate, I think. > I have been reviewing the code in the chat application and given the > abilities of the dbus do not feel that text messages will add all that > much complexity to the application. My original query was not as much > having a chat window in my activity but more of a Delphi like component > that I could drop into the buddy panel weld into my existing tubes and > be done with chat. This, I do believe is probably a fantastic thing to work on. What we really need in cases like this is, as you say, a chat widget that is based on the chat activity, having the same look, feel, options, etc. Just as we have an Abiword widget for text which can be used anywhere we should adopt a standard chat widget that can be designed and maintained by OLPC, so that the experience is always consistent and any fixes or improvements are automatically seen within any activity that makes use of it. Do those working on Chat see this as a viable possibility? > I have now become anxious about whether the 19x19 go board is feasible > on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go > world considers these less than optimal. There will be quite some time > before I get my G1G1's and only have sugar-jhbuild to run on. Is it > possible for anyone reading this to download the basic frame and report > if the 19x19 grid is usable? You may find it at > https://dev.laptop.org/git?p=projects/PlayGo;a=tree Even if you tab the toolbar, you'd wind up with a square that's about 41px in size. Our "recommended minimum" size is 45px square for a clickable area, so it sounds like you'll be fine, albeit on the smaller side. - Eben > Thanks > > - Gerard > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
On Fri, 2007-11-30 at 06:51 -0800, Gerard J. Cerchio wrote: > I have been reviewing the code in the chat application and given the > abilities of the dbus do not feel that text messages will add all that > much complexity to the application. My original query was not as much > having a chat window in my activity but more of a Delphi like component > that I could drop into the buddy panel weld into my existing tubes and > be done with chat. I think it wouldn't be hard to provide a set of gtk widgets that provide that functionality so activities can embed. > I have now become anxious about whether the 19x19 go board is feasible > on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go > world considers these less than optimal. There will be quite some time > before I get my G1G1's and only have sugar-jhbuild to run on. Is it > possible for anyone reading this to download the basic frame and report > if the 19x19 grid is usable? You may find it at > https://dev.laptop.org/git?p=projects/PlayGo;a=tree https://dev.laptop.org/~tomeu/playgo.png Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Ties Stuij wrote: > I must admit I didn't check your code but i found playing on a 19x19 > board in Hikaru no go on a GBA quite doable. And that has a 240x160 > screen!! I strongly suggest offering a 19x19 option, even if it is a > bit less clear. The game gets a lot more interesting with the > size-upgrade. > > /Ties > > > Thanks Ties, It comes up in 19x19. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
> I have now become anxious about whether the 19x19 go board is feasible > on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go > world considers these less than optimal. There will be quite some time > before I get my G1G1's and only have sugar-jhbuild to run on. Is it > possible for anyone reading this to download the basic frame and report > if the 19x19 grid is usable? You may find it at > https://dev.laptop.org/git?p=projects/PlayGo;a=tree I must admit I didn't check your code but i found playing on a 19x19 board in Hikaru no go on a GBA quite doable. And that has a 240x160 screen!! I strongly suggest offering a 19x19 option, even if it is a bit less clear. The game gets a lot more interesting with the size-upgrade. /Ties ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Eben Eliason wrote: >>> There are some activities where the chat is an integral part of the >>> participants' experience. In my case, chatter during the Go game may be >>> nonexistent to multiple lines of interactive tutorial per move to >>> razzing and praise from any of the observers. This is why I plan to have >>> a mute button that mutes all chat from observers. Unchecked, the button >>> allows kibitzing from all XO's in the buddy panel that joined the PlayGo >>> activity. >>> > > Well, the exact implementation isn't well defined at this point. > Obviously it's advantageous to be able to chat and work/play at the > same time. Doing this generically is hard because the screen is > rather small and there is no place where such a chat window can always > be positioned such that it isn't in the way. The overlay idea, > fullscreen or not, is the best general purpose solution we have so > far. Perhaps if we gain compositing support it can work somewhat like > growl on OSX; perhaps a global keystroke will initiate a new "chat > bubble" so to speak, so that joining in the conversation doesn't > require clicking a button on screen or shifting contexts. We're not > sure the details yet, but the more seamless we can make it the better. > > > Obviously you gain the most real-estate for the chat this way. > However, this also cuts off the activity completely, if only > temporarily, which may not be what we want in the end. I think > something slightly lighter would be desired. The question remains as > to whether or not it is repositionable, since we have yet to introduce > the idea of "windows." > > Obviously the push-to-talk method mitigates this problem, since the > "interface" for such a system requires one onscreen button, or even > one well known shortcut. > I would like to see the OLPC retain its non-windowed presentation style. I have run into people that have no idea how many windows are running. When they do not see the browser, they simply start another one, ignoring Z order and minimized applications. Don't laugh, my wife and I are the ISP for our condo complex and we have a few service calls along these lines. Given the OLPC environment, fixed frames and whole screen activity switching makes a lot of sense. So if I am performing an activity that does not require chat and wish to reference a colleague on line, hitting F3 and choosing the chat application is not offensive at all. For those activities that require chat, the interaction should happen in the context of the application's display structure. I am lucky that my particular application is square, this lends the rest of the rectangle to the buddy panel, which has the list of the participants in the upper half with the lower half containing the chat window. I am just finishing the basic game communications and will be moving on to the game player negotiation and setups this weekend. I am resisting tabbing the tool bar for these tasks if at all possible to prevent my square Go board from getting any smaller. I have been reviewing the code in the chat application and given the abilities of the dbus do not feel that text messages will add all that much complexity to the application. My original query was not as much having a chat window in my activity but more of a Delphi like component that I could drop into the buddy panel weld into my existing tubes and be done with chat. > I think there's something to be said for activities which don't > require much oomf. I think the "do one thing, do it well" mantra is a > good one, and one that might apply here. The screen is small, so > dedicate as much space as possible to the board, which has a large > number of squares. There is very limited RAM and CPU on these > machines, so just because your game doesn't eat too much doesn't mean > you should assume it will be reasonable to consume a significant > amount of these for "add-ons", not to mention greatly increase network > activity. I'm not sure that a multi-way video conference is even > feasible yet. > > I have now become anxious about whether the 19x19 go board is feasible on the OLPC. The game does have 9x9 and 13x13 modes of play. But the Go world considers these less than optimal. There will be quite some time before I get my G1G1's and only have sugar-jhbuild to run on. Is it possible for anyone reading this to download the basic frame and report if the 19x19 grid is usable? You may find it at https://dev.laptop.org/git?p=projects/PlayGo;a=tree Thanks - Gerard ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Simon McVittie wrote: > On Fri, 30 Nov 2007 at 07:51:38 -0500, Eben Eliason wrote: > >> I'm not sure that a multi-way video conference is even >> feasible yet. >> > > It's certainly not in the short term - the Telepathy and Farsight frameworks, > and the underlying protocols they currently use (Jingle), only support 1-1 > audio/video calls at this point, and we'd need a lot of API and protocol > design work to even start on this. > > Whenever we've talked about video-conferencing in the office, our VoIP > people's opinion has been that in practice we'd probably also need a (fairly > hefty) server to multiplex the streams for us, which doesn't work so well in > the OLPC use-case anyway. > Thanks, for clearing this up Simon. I was visualizing a one to one video connection. I think that Dr. Venkman has some very good advice "Don't cross the streams!" ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
On Fri, 30 Nov 2007 at 07:51:38 -0500, Eben Eliason wrote: > I'm not sure that a multi-way video conference is even > feasible yet. It's certainly not in the short term - the Telepathy and Farsight frameworks, and the underlying protocols they currently use (Jingle), only support 1-1 audio/video calls at this point, and we'd need a lot of API and protocol design work to even start on this. Whenever we've talked about video-conferencing in the office, our VoIP people's opinion has been that in practice we'd probably also need a (fairly hefty) server to multiplex the streams for us, which doesn't work so well in the OLPC use-case anyway. (disclaimer: I might be wrong, opinions might have changed; I'm not a VoIP hacker myself) Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
> > There are some activities where the chat is an integral part of the > > participants' experience. In my case, chatter during the Go game may be > > nonexistent to multiple lines of interactive tutorial per move to > > razzing and praise from any of the observers. This is why I plan to have > > a mute button that mutes all chat from observers. Unchecked, the button > > allows kibitzing from all XO's in the buddy panel that joined the PlayGo > > activity. Well, the exact implementation isn't well defined at this point. Obviously it's advantageous to be able to chat and work/play at the same time. Doing this generically is hard because the screen is rather small and there is no place where such a chat window can always be positioned such that it isn't in the way. The overlay idea, fullscreen or not, is the best general purpose solution we have so far. Perhaps if we gain compositing support it can work somewhat like growl on OSX; perhaps a global keystroke will initiate a new "chat bubble" so to speak, so that joining in the conversation doesn't require clicking a button on screen or shifting contexts. We're not sure the details yet, but the more seamless we can make it the better. > > This is not the functionality that I interpreted from Bert's comment: > > > >I thought this was intended to be a feature similar to the frame (and > >actually summoned by the frame key), layered on top of the activity, > >so it actually would work for *all* activities, Python or not. > > > >- Bert - > > > > I may be wrong in interpreting the ubiquitous chat interface as a full > > screen overlay on top of the application where the child must either > > chat into the overlay or switch modes to play the game. Are you > > suggesting that the ubiquitous chat can be relegated to its own panel on > > the activity's screen so there is no mode switching between chat and the > > "underlayed" activity Obviously you gain the most real-estate for the chat this way. However, this also cuts off the activity completely, if only temporarily, which may not be what we want in the end. I think something slightly lighter would be desired. The question remains as to whether or not it is repositionable, since we have yet to introduce the idea of "windows." Obviously the push-to-talk method mitigates this problem, since the "interface" for such a system requires one onscreen button, or even one well known shortcut. > > Would either of the two (or more) participants > > in the activity be able to mute observers? I find both of these > > functionalities fundamental to the activity experience and the tutored > > activity experience. This is an absolute fundamental requirement to any audio/video chat, in my opinion, for the sake of privacy. This requirement needs to make it into the HIG. > > Also, being that most of the video processing is offloaded in the Geode, > > I look forward to morphing the chat panel into a video call to my Go > > opponent. The PlayGo application takes very little resource, so there is > > plenty of ommf left over to run the video call. It would be the next > > best thing to playing in the same room. I think there's something to be said for activities which don't require much oomf. I think the "do one thing, do it well" mantra is a good one, and one that might apply here. The screen is small, so dedicate as much space as possible to the board, which has a large number of squares. There is very limited RAM and CPU on these machines, so just because your game doesn't eat too much doesn't mean you should assume it will be reasonable to consume a significant amount of these for "add-ons", not to mention greatly increase network activity. I'm not sure that a multi-way video conference is even feasible yet. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New ship.2 build 647
Le vendredi 30 novembre 2007 à 04:44 -0500, C. Scott Ananian a écrit : > We believe this build also fixes our linksys WDS interoperability > problems, and seems to be able to connect to more access points. > Still doesn't work for me: http://dev.laptop.org/ticket/4858#comment:13 G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New ship.2 build 647
On Nov 30, 2007 3:45 AM, Build Announcer Script <[EMAIL PROTECTED]> wrote: > http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build647/ > > -olpc-library-common.noarch 0:1-5 > +olpc-library-common.noarch 0:1-8 > -olpc-library-core.noarch 0:1-5 > +olpc-library-core.noarch 0:1-8 Our Best Build Yet (tm)! Please do test this build; it should fix all the blockers at http://dev.laptop.org/milestone/Ship.2 (although some tickets are still open because bugs need to be verified fixed). We believe this build also fixes our linksys WDS interoperability problems, and seems to be able to connect to more access points. SJ has also been burning the midnight oil to bring you our Best Library Yet (tm). So check out that content! Although I'm interested in hearing in olpc-update from old versions leads to funny behavior with ship.2 builds, so that I can fix this for update.1, I think we're most interested in hearing about problems that can be reproduced from clean installs, since that's how the vast majority of people will get ship.2 bits. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New ship.2 build 647
http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build647/ -olpc-library-common.noarch 0:1-5 +olpc-library-common.noarch 0:1-8 -olpc-library-core.noarch 0:1-5 +olpc-library-core.noarch 0:1-8 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
