Re: Fwd: Dailymotion for XO laptop
I have been following prior discussions about codecs in general (it is not about Gnash) and there is one thing I cannot understand. As I see for example a H.264 AVC codec license is 0 or 10 or 20 cents/device. If I am mistaken somebody please correct me. See: http://www.mpegla.com/avc/AVC_TermsSummary.pdf Sure, using Ogg over MP3 is totally okay, since it is not only free but better than MP3. But as others said all the free video codecs are crap compared to commercial ones. So my question: is there any reason that the OLPC cannot license one good quality codec for ~10 cents? (Not sure that it should be H.264 but anything else which runs with adequate speed on the XO, and has VideoLAN support.) Walter Bender wrote: Ben is right on target. Rather than going off shore to support proprietary codecs, we should be advocating the use of FOSS codecs. -walter On Jan 8, 2008 10:06 PM, Rob Savoye [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Benjamin M. Schwartz wrote: There might be some way to embed Theora in Flash in a way that Gnash can play, but this will never work in Adobe Flash. I strongly advise that, for OLPC, you avoid Flash altogether. Gnash can already handle both Ogg and Theora as external files just fine. We're also modifying Ming to be able to generate swf files with Ogg and Theora as embedded data. This requires extending the swf spec in a way that still says compatible for FLV, ON2, and MP3. To go along with this, I've been working on a clone of the Adobe Media Server, so we can steam free codecs. Right now you can only do this with icecast, but it doesn't speak the flash protocols, which Gnash now supports. - rob - ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ 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: Better build announcement script, anyone?
Ivan, I wasn't referring just to the packages, but also to the ChangeLog entries. Cheers, Reinier Ivan Krstić wrote: On Jan 8, 2008, at 5:54 PM, Reinier Heeres wrote: As an added bonus, it should be possible to create a diff between *any* two versions. See also http://dev.laptop.org/~krstic/diffbuildlog.py.txt -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
On Tue, 2008-01-08 at 19:34 -0700, Rob Savoye wrote: Sigh, I am getting so tired of this issue with codecs... Gnash for the XO is built without support for any proprietary audio or video codecs. Because of the patent laws, the OLPC project (which is based in the US) cannot redistribute these codecs. So, although Gnash supports dailymotion just fine, it'll never work on the XO unless it's built with support for these codecs, namely FLV, ON2, and MP3. Does Gnash not use gstreamer and hence work with the extra codec plugins which are already available in livna? Having to _build_ it with the problematic support would seem to be a poor design decision. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
On Tue, 2008-01-08 at 20:06 -0700, Rob Savoye wrote: To go along with this, I've been working on a clone of the Adobe Media Server, so we can steam free codecs. Right now you can only do this with icecast, but it doesn't speak the flash protocols, which Gnash now supports. Oooh. Gnash now supports RTMP? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Better build announcement script, anyone?
On Jan 8, 2008, at 23:54 , Reinier Heeres wrote: Hi all, I recently started working on a new build announcer script in python. It's available at dev.laptop.org/~rwh/announcer. Looks good :) I'd like to compare the output of my script and the present announcer for a couple of days to make sure it's an improvement. Can you make it produce the full HTML logs, too? They're rather handy for reference: http://dev.laptop.org/~bert/joyride-pkgs.html Maybe someone could suggest an official URL for them? Then we could consider switching. Sure. Let's coordinate on IRC then. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 676
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build676/ -matchbox-window-manager.i386 0:1.2-1 +matchbox-window-manager.i386 0:1.2-3.20070628svn -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
[EMAIL PROTECTED] wrote: The other option is to write implementations of the codecs that avoid the patents. Whether that is possible depends on the exact wording of the patent, and sometimes it takes a few weeks working with a good patent attorney to work out exactly what the patent really says. Sometimes it just isn't possible. We really need a open project to do patent analysis of this kind and determine which of these key patents (not just codecs, but also other important blocking patents) can be avoided, and which ones are too tied to the format to avoid. Perhaps the OLPC project would provide a good bit of motivation for people to do this type of work? 1. There are two kinds of good patent attorneys. One kind works pro bono for free software and the other gets paid big bucks by patent holders. It's not just a question of quality or attorney or length of time spent. It's a question of two competing sides of a specific and very detailed technical and legal argument being thrashed out in the press and in the courts. If you head to the Groklaw web site, you can see this sort of thing (from the free software side). This process does not take a few weeks but *decades*. 2. I personally don't think the OLPC project has the bandwidth or the energy to get involved in such a struggle. As the recent events between OLPC and Intel have showed, when you wrestle with a pig, both of you get mud all over but only the pig enjoys it. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #5859 NORM FutureF: Need a way to tactily distinguish keys on top row
All three bars along the top row of the keyboard act as analog sliders when the FN key is held down. They have four distinct key assignments under normal operation. -walter On Jan 9, 2008 2:51 AM, Zarro Boogs per Child [EMAIL PROTECTED] wrote: #5859: Need a way to tactily distinguish keys on top row --+- Reporter: mgorse | Owner: walter Type: enhancement | Status: new Priority: normal | Milestone: FutureFeatures Component: keyboards| Version: Resolution: |Keywords: Verified: 0|Blocking: Blockedby: | --+- Comment(by AlbertCahalan): Notches along both edges wouldn't be too bad. That leaves the top smooth, which is important for the slider. The non-slider keys could just be made distinct. Having them connected at all is undesirable. The slider is a funny case. Ideally, the user would not know or care that there are 7 distinct buttons. Ideally, there would be an infinite number of buttons. It is after all supposed to be a slider. -- Ticket URL: http://dev.laptop.org/ticket/5859#comment:3 One Laptop Per Child http://dev.laptop.org OLPC bug tracking system -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jffs zlib tuning
On 08/01/08 17:09 -0800, William Fisher wrote: Jordan Crouse wrote: On 08/01/08 12:06 -0500, Bernardo Innocenti wrote: (cc CP, aleph) David Woodhouse wrote: 1. Did anybody profile the kernel while reading files? Last thing I red on this list is that the profiler does not work on the XO in kernel mode. Did anybody fix that I believe that standard kernel profiling (on timer ticks) has always worked, and even continues to work even though we use a tickless kernel now. I think oprofile also works. oprofile works, but for some reason it cannot generate call graphs. It vaguely remember that the problem was that on the Geode we were using sw timers rather than NMI as a timing source. Right - but that should only prevent us from benchmarking within interrupts in the kernel - it shouldn't have any effect on our userland benchmarking. I'm no oprofile expert (I couldn't get it working at all when I tried it the other day), but do you have the debug version of libc loaded too? Maybe it can't find the symbols. Jordan If you have NMI interrupts selected for Oprofile, you can also get samples from the other lower level interrupt handlers. Since OProfile can be run in either NMI interrupts or normal timer based interrupts. We can't use NMI, because we have no mechanism for causing the NMIs. Modern processors such as the k8 use registers called event counters to count a number of events between sample periods (events being some processor quality like number of instructions executed or number of cache misses). These event counters can be set up in such a way that they cause a NMI when the counter rolls over. This is how oprofile takes advantage of the silicon. The kicker is that even though the Geode has event counters, we cannot set them up to cause a NMI. So, with that mechanism lost, we're stuck with the timer tick. This has been discussed several times over the lifetime of the project - you can go back over the archives of the list and see our past conclusions on this matter. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
mesh portal discovery
Right now we have a problem with mesh portal discovery. The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... There are larger issues which will probably need a day of discussion later surrounding IPv6 deployment, such as cooperation between RADVD and mesh portal discovery... (Please defer discussion on this right now) wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 676
Have 674. Don't quite know if this is equivalent or not, but instead of doing 'olpc-update' for 675 and 676, I've just been using 'yum update'. Seems to upgrade the same modules as the new builds. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 676
On Wednesday 09 January 2008, Mikus Grinbergs wrote: Have 674. Don't quite know if this is equivalent or not, but instead of doing 'olpc-update' for 675 and 676, I've just been using 'yum update'. Seems to upgrade the same modules as the new builds. that will work for everything except activities which are not shipped as rpms Dennis ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
John Watlington [EMAIL PROTECTED] wrote on 01/09/2008 11:34:29 AM: Right now we have a problem with mesh portal discovery. The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... This is the expected behavior since the special anycast address is only used during discovery. There are larger issues which will probably need a day of discussion later surrounding IPv6 deployment, such as cooperation between RADVD and mesh portal discovery... (Please defer discussion on this right now) The largest issue is how wrong, ugly and painful is to use DHCP on a mesh network. Because of RADV, IPv6 doesn't have that issue. The original mesh portal discovery method was proprietory but also extremely lightweight and did what it was supposed to do with minimal code. Using DHCP is the absolutely ugliest hack that I have even encounter because you can't legally have more than one server per layer-2 network to begin with, it makes the address configuration inconsistent (different method for a school server and different for a non-school server mesh) and to add insult to the injury, it forces the use of a DHCP server process, utilizing several megabytes of RAM in every laptop to just distribute name server and GW ip addresses, having effectively broken Internet sharing via the mesh for several months now. I am not even mentioning the uneccesary broadcasts forced by the fact that you have to have pretty short leases given the dynamic character of the network. We put a lot of effort to put the anycast address support in the mesh, to specifically address the need of selecting the optimal path to a specific service in the path discovery process itself. We ended up with the DHCP monstrocity just so that we don't use anything new in what is in effect a new way of doing local area networking. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jffs zlib tuning
On Jan 9, 2008 10:51 AM, Jordan Crouse [EMAIL PROTECTED] wrote: We can't use NMI, because we have no mechanism for causing the NMIs. Modern processors such as the k8 use registers called event counters to count a number of events between sample periods (events being some processor quality like number of instructions executed or number of cache misses). These event counters can be set up in such a way that they cause a NMI when the counter rolls over. This is how oprofile takes advantage of the silicon. The kicker is that even though the Geode has event counters, we cannot set them up to cause a NMI. So, with that mechanism lost, we're stuck with the timer tick. This has been discussed several times over the lifetime of the project - you can go back over the archives of the list and see our past conclusions on this matter. There is still the possibility of using the MFGPT block in 5536 to cause periodic NMIs. That would be similar to oprofile's RTC or timer interrupt mode, but with support to profile interrupt handler code, and pretty-good granularity (14MHz-based) The perfmon-rollover style (not available on LX) is certainly the best way to do something like oprofile, but if you can make periodic NMIs fast enough, you should be able to get pretty close to similar quality. This completely new oprofile mode would be very specific to GX/LX/5536, but it would improve oprofile usefulness if someone wants to make the (pretty large) effort. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008 11:21 AM, Michail Bletsas [EMAIL PROTECTED] wrote: ... The largest issue is how wrong, ugly and painful is to use DHCP on a mesh network. Because of RADV, IPv6 doesn't have that issue. The original mesh portal discovery method was proprietory but also extremely lightweight and did what it was supposed to do with minimal code. ... I'm late to the party. How/who was it proprietary? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #5859 NORM FutureF: Need a way to tactily distinguish keys on top row
Walter Bender wrote: All three bars along the top row of the keyboard act as analog sliders when the FN key is held down. They have four distinct key assignments under normal operation. Yes. And each one of the analog sliders is actually *8* keys rather than just 4. We currently have no mappings in libX11 for these. Me and Jim know about the whole story. -- \___/ |___| 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: mesh portal discovery
On Wed, 2008-01-09 at 12:18 -0600, Charles Durrett wrote: On Jan 9, 2008 11:21 AM, Michail Bletsas [EMAIL PROTECTED] wrote: ... The largest issue is how wrong, ugly and painful is to use DHCP on a mesh network. Because of RADV, IPv6 doesn't have that issue. The original mesh portal discovery method was proprietory but also extremely lightweight and did what it was supposed to do with minimal code. ... I'm late to the party. How/who was it proprietary? The original method used UDP packets with a custom format. I wouldn't say proprietary so much as non-standard since the code that created the UDP packets was open for all to see. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO emulation?
My XO is on order and I don't know when it will arrive. I have filled my main system up with crap trying to get an XO emulator to work. I now have a system just for XO emulation. So which OS/QEMU/VM works best. I am really tired of working on this problem. I want to get on with XO development. Any suggestions will be appreciated. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1524
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1524/ -NetworkManager.i386 1:0.6.5-0.8.svn2925.olpc2 +NetworkManager.i386 1:0.6.5-0.8.svn3218.olpc2 -coreutils.i386 0:6.9-5.fc7 +coreutils.i386 0:6.9-6.fc7 -glibc-common.i386 0:2.6.90-19 +glibc-common.i386 0:2.7-2 -glibc.i686 0:2.6.90-19 +glibc.i686 0:2.7-2 -sugar-base.i386 0:0.2.0-1 +sugar-base.i386 0:0.2.1-1 -tzdata.noarch 0:2007i-1.fc7 +tzdata.noarch 0:2007k-1.fc7 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO emulation?
I have had great success using vmware. Download an image file from here: http://dev.laptop.org/pub/virtualbox/ (I have been using build 653) and then open it with vmware. I also tried qemu and virtualbox, but vmware was by far the easiest to get going. -josh On Jan 9, 2008, at 10:31 AM, Kent Loobey wrote: My XO is on order and I don't know when it will arrive. I have filled my main system up with crap trying to get an XO emulator to work. I now have a system just for XO emulation. So which OS/QEMU/VM works best. I am really tired of working on this problem. I want to get on with XO development. Any suggestions will be appreciated. ___ 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: mesh portal discovery
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote: Right now we have a problem with mesh portal discovery. The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... Legacy IP doesn't work well and doesn't really give us what we need in the long term... or even the medium term. We've known that all along. What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 677
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build677/ +cairo.i386 0:1.4.10-1.fc7 -cairo.i386 0:1.4.12-1.fc7 -olpc-utils.i386 0:0.59-1.olpc2 +olpc-utils.i386 0:0.63-1.olpc2 -sugar-datastore.noarch 0:0.7.2-1 +sugar-datastore.noarch 0:0.7.3-1.olpc2 +totem.i386 0:2.18.2-11 -totem.i386 0:2.18.2-5.olpc2 +totem-mozplugin.i386 0:2.18.2-11 -totem-mozplugin.i386 0:2.18.2-5.olpc2 +totem-plparser.i386 0:2.18.2-11 -totem-plparser.i386 0:2.18.2-5.olpc2 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008, at 2:08 PM, David Woodhouse wrote: On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote: Right now we have a problem with mesh portal discovery. The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... Legacy IP doesn't work well and doesn't really give us what we need in the long term... or even the medium term. We've known that all along. What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this problem. It's easy to discover the shortest way out of the mesh (nearest mesh portal), but setting up the larger mesh networkl infrastucture means you also need to provide a way to route packets back INTO the mesh through the MPP nearest the destination laptop. I have yet to see a good description of how to make IPv6 work right on a mesh with multiple portals.One would be welcome! I have such a method for IPv4 defined, but due to an error in modifying the DHCP client, it doesn't handle laptops moving around in the mesh once they've chosen an MPP. (BTW, the error was mine) wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote: Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this problem. It's easy to discover the shortest way out of the mesh (nearest mesh portal), but setting up the larger mesh networkl infrastucture means you also need to provide a way to route packets back INTO the mesh through the MPP nearest the destination laptop. I have yet to see a good description of how to make IPv6 work right on a mesh with multiple portals.One would be welcome! I talked to cscott and Michail about this briefly when I was in Boston in December. I suspect we should turn off the automatic response to RA in the kernel, and handle it in userspace. We need some special handling in userspace anyway, to pick up DNS server details from RA. We can also check the mesh path length to the origin of each RA we see, and choose the best one. I have such a method for IPv4 defined, but due to an error in modifying the DHCP client, it doesn't handle laptops moving around in the mesh once they've chosen an MPP. (BTW, the error was mine) Is there a hack which would work around that -- like reducing the lease time? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. You definitely live in a universe different from mine. Regardless of how much we try to make the XO to only talk to other XOs at the p2p application level, there is this small thingy out there called the web which is going to require Legacy IP for the foreseeable future... M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008, at 2:40 PM, David Woodhouse wrote: On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote: Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this problem. It's easy to discover the shortest way out of the mesh (nearest mesh portal), but setting up the larger mesh networkl infrastucture means you also need to provide a way to route packets back INTO the mesh through the MPP nearest the destination laptop. I have yet to see a good description of how to make IPv6 work right on a mesh with multiple portals.One would be welcome! I talked to cscott and Michail about this briefly when I was in Boston in December. I suspect we should turn off the automatic response to RA in the kernel, and handle it in userspace. We need some special handling in userspace anyway, to pick up DNS server details from RA. We can also check the mesh path length to the origin of each RA we see, and choose the best one. Sounds like a plan. Sometime next week we should start outlining the work that needs to happen. I have such a method for IPv4 defined, but due to an error in modifying the DHCP client, it doesn't handle laptops moving around in the mesh once they've chosen an MPP. (BTW, the error was mine) Is there a hack which would work around that -- like reducing the lease time? Heh. JG wants to increase the lease time --- I want to reduce it. It doesn't really make a difference, as once the lease time is expired the dhclient first tries to request the existing lease from the previous DHCP server. As long as it can communicate with it by hopping through the mesh, it will renew the existing lease and never discover a closer MPP/DHCP server This was the problem that prompted my original message on this thread. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:40:46 PM: We can also check the mesh path length to the origin of each RA we see, and choose the best one. The way this was originally implemented in a way that can be used for any well defined service (not just network gateways), was to assign an anycast MAC address to such well defined services. So when a node is looking to see if there is another node providing such a service in the mesh, all that it has to do is a path discovery for the MAC address corresponding to that service. If the path discovery is successful, both the presence of the service as well as the optimal path to it has been discovered. In the case of the mesh portal (A NAT Internet Gateway in our case) we need to get back the IP address of the gateway as well as DNS info. A simple python server listening at a predefined port was providing that. That simple server has been replaced by a complete DHCP server in our current implementation. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008, at 2:55 PM, Michail Bletsas wrote: David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:40:46 PM: We can also check the mesh path length to the origin of each RA we see, and choose the best one. The way this was originally implemented in a way that can be used for any well defined service (not just network gateways), was to assign an anycast MAC address to such well defined services. So when a node is looking to see if there is another node providing such a service in the mesh, all that it has to do is a path discovery for the MAC address corresponding to that service. If the path discovery is successful, both the presence of the service as well as the optimal path to it has been discovered. In the case of the mesh portal (A NAT Internet Gateway in our case) we need to get back the IP address of the gateway as well as DNS info. A simple python server listening at a predefined port was providing that. That simple server has been replaced by a complete DHCP server in our current implementation. The DHCP server was needed anyway. And to implement shortest path routing both for sent and received packets, we needed a mechanism for receiving an IP address that reflected the nearest MPP anyway (or use NAT, something we would like to avoid inside the school) wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 14:43 -0500, Michail Bletsas wrote: What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. You definitely live in a universe different from mine. Regardless of how much we try to make the XO to only talk to other XOs at the p2p application level, there is this small thingy out there called the web which is going to require Legacy IP for the foreseeable future... NAT-PT and proxying should solve that problem relatively simply. I should investigate the implementation at http://tomicki.net/naptd.php -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
The DHCP server was needed anyway. And to implement shortest path routing both for sent and received packets, we needed a mechanism for receiving an IP address that reflected the nearest MPP anyway (or use NAT, something we would like to avoid inside the school) I completely fail to see why we need the DHCP server to get the IP address of the nearest MPP or get the optimal path to and from it. As for the multiple radio scenario at the schools, you can address that with two different ways: bridging between the interfaces on the server or -if you want something quicker-, use a different autoIP range for each channel. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 02:57:50 PM: NAT-PT and proxying should solve that problem relatively simply. I should investigate the implementation at http://tomicki.net/naptd.php Running application proxies on every XO that wants to act as a mesh portal? M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
David Woodhouse [EMAIL PROTECTED] wrote on 01/09/2008 03:17:30 PM: On Wed, 2008-01-09 at 15:15 -0500, Michail Bletsas wrote: Running application proxies on every XO that wants to act as a mesh portal? Running NAT-PT. Since they're required to run NAT as it is anyway, that shouldn't be too much of a problem. And this 'mesh portal' mode isn't something we really have working anyway. It does require application level proxies to look inside packets (FTP and DNS are examples, per its documentation). And we had the mesh portal thing working perfectly fine until we decided to add DHCP in the picture M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 9 Jan 2008, John Watlington wrote: In the case of the mesh portal (A NAT Internet Gateway in our case) we need to get back the IP address of the gateway as well as DNS info. A simple python server listening at a predefined port was providing that. That simple server has been replaced by a complete DHCP server in our current implementation. The DHCP server was needed anyway. And to implement shortest path routing both for sent and received packets, we needed a mechanism for receiving an IP address that reflected the nearest MPP anyway (or use NAT, something we would like to avoid inside the school) you really don't want to have your IP address change becouse you moved to have a different MPP closer to you. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
I completely fail to see why we need the DHCP server to get the IP address of the nearest MPP or get the optimal path to and from it. The MPP discovery mechanism originally proposed worked great for getting packets out of the mesh through the shortest path. The problem was that outside of running NAT on each MPP, there wasn't a good way to ensure that packets sent to that laptop entered the mesh through the same MPP. That is currently handled (in IPv4) by using a different DHCP range for each MPP, and routing to the appropriate MPP based on those ranges. As for the multiple radio scenario at the schools, you can address that with two different ways: bridging between the interfaces on the server or -if you want something quicker-, use a different autoIP range for each channel. We briefly discussed using a different autoIP range, and decided it was difficult to implement. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
The MPP discovery mechanism originally proposed worked great for getting packets out of the mesh through the shortest path. The problem was that outside of running NAT on each MPP, there wasn't a good way to ensure that packets sent to that laptop entered the mesh through the same MPP. The only reason that I can see to use DHCP is if you want to distribute routable IPv4 addresses, something that would be glorious if it could happen but which I don't see happening very often. If you are not running NAT on the MPPs and you have multiple MPPs per mesh and the external routing protocol decided that packets should return through a different portal, what much do you think you are gaining by using the same path inside the mesh (which b.t.w. is different in each direction anyway!)? We briefly discussed using a different autoIP range, and decided it was difficult to implement. Again fail to see why - it can be non-standard but definitely not difficult to implement. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 9 Jan 2008, John Watlington wrote: I completely fail to see why we need the DHCP server to get the IP address of the nearest MPP or get the optimal path to and from it. The MPP discovery mechanism originally proposed worked great for getting packets out of the mesh through the shortest path. The problem was that outside of running NAT on each MPP, there wasn't a good way to ensure that packets sent to that laptop entered the mesh through the same MPP. That is currently handled (in IPv4) by using a different DHCP range for each MPP, and routing to the appropriate MPP based on those ranges. this sounds like the mobile IP problem. could you do something along the lines of having the MPP boxes within a mesh talk to each other (either over the mesh or over the Internet) so that they know what boxes are closest to each one. then have the mesh route the traffic out to the nearest MPP. response traffic would go to the MPP that allocated the IP address, and that box then tunnels the packet over to the MPP box closest to the laptop (similar to how LVS does load balancing), and that box then sends it over the radio. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
Hi all, Thanks a lot for your help and comments. However it seems quite difficult for us to encode our videos in Theora+Vorbis right now. I'm gonna talk to different people in the company to get their opinion and see what we can do. In the meantime, I've heard of the Helix Media Player http://en.wikipedia.org/wiki/Helix_(project) for the OLPC project? It won't be of any help? Thanks again Sebastien Adgnot On Jan 9, 2008 5:25 PM, Bill Nottingham [EMAIL PROTECTED] wrote: Jake Beard ([EMAIL PROTECTED] ) said: Hopefully, later this year we'll see a completely open Java, and then see Java on the XO. Flash is terrible. If it were possible, I'd prefer to see an all-Java solution. That being said, in my experience both with closed and open Java implementations, I wouldn't expect a huge speed improvement on the OLPC from switching from Flash to Java. Bill ___ 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: #5859 NORM FutureF: Need a way to tactily distinguish keys on top row
Is it 8 or 7? I thought it was the four + 3 intermediaries. -walter On Jan 9, 2008 1:26 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Walter Bender wrote: All three bars along the top row of the keyboard act as analog sliders when the FN key is held down. They have four distinct key assignments under normal operation. Yes. And each one of the analog sliders is actually *8* keys rather than just 4. We currently have no mappings in libX11 for these. Me and Jim know about the whole story. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing OLPC firmware Q2D08
Will it be auto-installed when I olpc-update to latest joyride, or will it have to be manualy installed? -ffm On Jan 9, 2008 4:33 PM, Mitch Bradley [EMAIL PROTECTED] wrote: http://wiki.laptop.org/go/OLPC_Firmware_q2d08 This firmware has a large number of mostly-minor improvements. It is a test candidate for the Update.1 release. At present, a signed version of it is not available, so only developers can install it. ___ 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: mesh portal discovery
On Wed, 2008-01-09 at 15:59 -0500, John Watlington wrote: On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote: The MPP discovery mechanism originally proposed worked great for getting packets out of the mesh through the shortest path. The problem was that outside of running NAT on each MPP, there wasn't a good way to ensure that packets sent to that laptop entered the mesh through the same MPP. The only reason that I can see to use DHCP is if you want to distribute routable IPv4 addresses, something that would be glorious if it could happen but which I don't see happening very often. Neither do I. But I don't want to impose a NAT between two laptops in the same school. It will break P2P applications. If you are not running NAT on the MPPs and you have multiple MPPs per mesh and the external routing protocol decided that packets should return through a different portal, what much do you think you are gaining by using the same path inside the mesh (which b.t.w. is different in each direction anyway!)? I don't care about using the same path, but sending packets for six hops through the mesh when proper routing can reduce it to a single hop seems like piss-poor design. And it makes the mesh interfaces on a single server serve the entire school. Why bother with multiple MPPs at all ? We briefly discussed using a different autoIP range, and decided it was difficult to implement. Again fail to see why - it can be non-standard but definitely not difficult to implement. IIRC, Dan Williams was the person looking into it. It wasn't a Network Manager change, it was a change to Avahi, and would either have to be pushed upstream or maintained indefinitely by us. Plus, AutoIP addresses aren't EVER supposed to be routed --- they are strictly link local due to the assignment process. Thanks for the discussion --- we need to figure out a solution for IPv6 going forward, as none of the current approaches will absolutely not extend to IPv6. - DHCP did what we needed back then, namely 1) a robust discovery mechanism 2) well-tested backoff mechanisms 3) well-known and standardized behavior and packet format 4) well-tested and security audited server and client In the School Server case, using DHCP as the allowed us to collapse two steps of the connection process into one. With the previous method, you would have to _both_ find the MPP using the non-standard MPP discovery method, and second do a DHCP run to get your address from the school server. Using DHCP here _already_ can provide the address of your gateway. You could conceivably do both these operations in parallel but since you have to do DHCP anyway, it's pointless to do some other MPP discovery mechanism. In a school setting autoip might work, but might mean more traffic because of potential address conflicts and the resolution process. So if you want dynamic addressing in the school, DHCP is about the only easy way to do that, and once you're using DHCP the old MPP discovery mechanism is pointless. The above benefit does not apply in the XO-as-MPP case because autoip addressing is used, however the same codepath is used in NetworkManager as the school server case, and therefore there is less code to maintain, and fewer codepaths to test, and fewer opportunities for stuff to go wrong. The only real solution to this problem that doesn't suck is to use IPv6 auto addressing for everything. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing OLPC firmware Q2D08
ffm wrote: Will it be auto-installed when I olpc-update to latest joyride, or will it have to be manualy installed? Manual. -ffm On Jan 9, 2008 4:33 PM, Mitch Bradley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://wiki.laptop.org/go/OLPC_Firmware_q2d08 This firmware has a large number of mostly-minor improvements. It is a test candidate for the Update.1 release. At present, a signed version of it is not available, so only developers can install it. ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
mp3 player options for XO?
currently (recent joyride versions) if you try to play a mp3 it fires up etoys, which then takes you through some very un-suger-like options before playing the mp3, but the player it's using doesn't seem to respond to any keys (for pause/play/FF/rev/etc) and the progress bar does not appear to work. what should be used for this sort of thing? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
John, The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... You probably don't want that: a mesh point might have equal cost routes to several mesh portals. In that case you want some hysteresis: only change to a new MPP if it offers a big advantage over the current one. As long as it can communicate with it by hopping through the mesh, it will renew the existing lease and never discover a closer MPP/DHCP server This was the problem that prompted my original message on this thread. One way to do this would be to run a simple daemon that 1. Periodically sends traffic to the anycast address. If you want to use dhclient for this ( assuming it is patched as described here: http://www.cozybit.com/projects/mpp-utils/index.html#update ) you could send frames to the anycast address like this: # dhclient eth0 -1 -lf /dev/null -sf /bin/true 2. Compare the metric of the best mpp with the current mpp. This can be done via iwpriv fwt_list calls. 3. If the cost difference justifies it, wipe out the existing leases and re-discover # rm /var/lib/dhcp3/* ; dhclient eth0 Cheers, Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SD resume timing
At today's bug status meeting, I was asked to investigate SD card resume timing from OFW. The range was 24 mS to 187 mS , depending on which SD card is plugged in. The fixed component of that time is about 5 mS, including re-initing the host controller and issuing a sequence of card commands that determine which kind of card you have (SD, SDHC, MMC, etc). The variable component is the wait for card to power up step - you have to repeatedly issue a set operating conditions command until you get a specific response indicating that the card is ready. I tried all of the cards I have multiple times, with consistent results. After the tested resume sequence, reads from the card worked. Here is the variable component of the time for my cards: 19 mS PQI 2GB SD Hi-Speed 150 37 mS SanDisk 32 MB SD 41 mS SanDisk 1GB SD Extreme III 73 mS Kingston 256 MB MMC+ 75 mS Transcend 4GB SD 150x 182 mS Panasonic 512 MB SD Pro high speed I don't have any SDHC cards. If you wish to try the tests yourself, here is a recipe: ok select /sd ok patch 0 14 attach-card ok patch 0 14 attach-card ok patch 0 a attach-card ok patch 400 64 wait-powered ok patch 1 a wait-powered ok s t( setup-host attach-card drop )t After you issue the last command, press the power button to resume; the SD resume time will be displayed in microseconds. You can repeat that last command as necessary, inserting new cards if you wish. The patches shorten various time delays that are in the existing driver. Empirically, all of my cards seem to work fine without those delays. The first 3 patches eliminate a total of 50 mS (0x14 + 0x14 + 0x0a) from the fixed component of the time. The last 2 patches decrease the granularity of the variable component of the time from 10 mS to 1 mS. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
Thanks for offering help. However, I was thinking more about ressources (time, people, storage, encoding, priorities, etc.). Anyway, I'm going to report what everybody wrote and see if we can make it soon ... or later. Thanks Sebastien On Jan 9, 2008 10:32 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: On Wed, 2008-01-09 at 22:19 +0100, Sebastien Adgnot wrote: Hi all, Thanks a lot for your help and comments. However it seems quite difficult for us to encode our videos in Theora+Vorbis right now. I'm gonna talk to different people in the company to get their opinion and see what we can do. If your difficulty is technical, then there are dozens of multimedia and web software experts here who would love to step in and help you (at no charge). In the meantime, I've heard of the Helix Media Player http://en.wikipedia.org/wiki/Helix_(project) for the OLPC project? It won't be of any help? The Helix Player is no longer included in the OLPC distribution, though it is available as an optional download. Helix Player only provides Theora video. The user can manually download additional binary-only codecs, but this is not supported by OLPC. This is no easier than having users manually install Adobe's binary Flash plugin, which OLPC also cannot distribute. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 676
I've just been using 'yum update'. Seems to upgrade the same modules as the new builds. that will work for everything except activities which are not shipped as rpms Would 'sugar-install-bundle' work for activities shipped as .xo ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird WLAN problem after stupid upgrade attempt
I've updated to the Q2D08 firmware now. Whereas the '07 firmware seemed to run the test /wlan ok, but the wlan card wasn't visible to the regular OS, now when I run the same command on the '08 firmware I get ok test /wlan Device /wlan not found. ok So what's the verdict. Do folks think I should RMA this thing? It seems like it got busted merely via software - which one would normally not expect to be possible. (-: Tom ;-) On Jan 6, 2008, at 12:56 AM, Tom Seago wrote: Hi Mitch. I got my developer key and ran test /wlan at the ofw prompt. That seemed to work! At least, it scrolled a fairly large amount of info up the screen which appeared to be the stats of various visible wifi networks. However, all my problems where the OS can't see the card remain. It makes me happy that this appears to be software not hardware. It still confuses me how I managed to get into this bizarre situation though. Is there a way to do any more complete of a device wipe beyond the normal reflashing procedure using the signed build from a usb stick? I appreciate your help. I hope we can figure out what's up with this thing. (-: Tom ;-) On Jan 4, 2008, at 10:22 AM, Mitch Bradley wrote: Tom Seago wrote: ... Another thing I have done is run the POST diagnostics by holding the left rocker button during boot. I did this on both machines at the same time to diff the results. Both say that usb port 0 is in use - good. But the working machine did scroll some wlan diagnostic information up the screen at the end of the the video tests that the broken machine did not do. The broken machine did not report an error - but it clearly did not run the same wlan test. Chris Ball wrote: Hi Tom, Once you have your developer key, please run: ok test /wlan If that fails too, it should be clear that we need to RMA and replace your laptop. Thanks! The POST diags that Tom ran include the test /wlan step. That diagnostic info that scrolled by is a dump of the access point scan info. It happens just before the touchpad test. My recommendations: a) Remove all power - AC and battery - for a few seconds to reset the wireless really well, then reboot and try the POST diags again. b) If that doesn't fix it, email me when you get your developer key and I'll work with you on IRC to see if we can learn more about the failure details. Mitch Bradley ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
PATCH: add --loginpause to mingetty
Hello Florian,
the attached patches add an option to pause login until the user hits
a key.
We need something like it on OLPC because:
- we don't want to set an empty password for either user root or olpc
- at the same time, we want to allow users to login as root at the
console
- finally, we do not wish to waste memory on shells the user hasn't
yet used
The security model we are implementing is very different from UNIX: we
ultimately trust the user at the console, but we don't trust applications
and we don't want them to gain root privileges using su or sudo with no
password.
I'm committing these changes to the OLPC-2 branch of mingetty in
Fedora CVS. Please, let me know you'd like to merge them or
something similar.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
diff -rup mingetty-1.07.orig/mingetty.8 mingetty-1.07/mingetty.8
--- mingetty-1.07.orig/mingetty.8 2003-05-14 04:55:43.0 -0400
+++ mingetty-1.07/mingetty.8 2008-01-09 18:17:06.0 -0500
@@ -6,6 +6,7 @@ mingetty \- minimal getty for consoles
[\-\-noclear] [\-\-nonewline] [\-\-noissue] [\-\-nohangup] [\-\-nohostname]
[\-\-long\-hostname] [\-\-loginprog=/bin/login] [\-\-nice=10] [\-\-delay=5]
[\-\-chdir=/home] [\-\-chroot=/chroot] [\-\-autologin username]
+[\-\-loginpause]
.I tty
.PP
.SH DESCRIPTION
@@ -62,6 +63,11 @@ Log the specified user automatically in
a login name and password. Check the \-f option from
.B /bin/login
for this.
+.TP
+.B \-\-loginpause
+Wait for any key before dropping to the login prompt.
+Can be combined with \fB\-\-autologin\fR to save memory by lazily spawning
+shells.
.PP
.SH ISSUE ESCAPES
.B mingetty
diff -rup mingetty-1.07.orig/mingetty.c mingetty-1.07/mingetty.c
--- mingetty-1.07.orig/mingetty.c 2004-01-03 08:15:56.0 -0500
+++ mingetty-1.07/mingetty.c 2008-01-09 18:10:15.0 -0500
@@ -74,6 +74,8 @@ static char *ch_dir = NULL;
static int priority = 0;
/* automatic login with this user */
static char *autologin = NULL;
+/* try to read a char before dropping to login prompt */
+static int loginpause = 0;
/* error() - output error messages */
static void error (const char *fmt, ...)
@@ -283,6 +285,10 @@ static void do_prompt (int showlogin)
}
fclose (fd);
}
+if (loginpause) {
+ puts([press ENTER to login]);
+ getc(stdin);
+ }
if (nohostname == 0)
printf (%s , hn);
if (showlogin)
@@ -327,11 +333,13 @@ static void usage (void)
[--nohangup] [--nohostname] [--long-hostname]
[--loginprog=/bin/login] [--nice=10] [--delay=10]
[--chdir=/home] [--chroot=/chroot] [--autologin=user]
+ [--loginpause]
tty' with e.g. tty=tty1, progname);
}
static struct option const long_options[] = {
{ autologin, required_argument, NULL, 'a' },
+ { loginpause, no_argument, loginpause, 'p' },
{ chdir, required_argument, NULL, 'w' },
{ chroot, required_argument, NULL, 'r' },
{ delay, required_argument, NULL, 'd' },
@@ -366,7 +374,7 @@ int main (int argc, char **argv)
putenv (TERM=linux);
#endif
- while ((c = getopt_long (argc, argv, a:d:l:n:w:r:, long_options,
+ while ((c = getopt_long (argc, argv, a:p:d:l:n:w:r:, long_options,
(int *) 0)) != EOF) {
switch (c) {
case 0:
diff -u -p -r1.2 mingetty-1.00-opt.patch
--- mingetty-1.00-opt.patch 9 Sep 2004 08:31:33 - 1.2
+++ mingetty-1.00-opt.patch 10 Jan 2008 00:15:11 -
@@ -1,10 +1,11 @@
--- mingetty-1.00/Makefile.rpm Mon Mar 4 15:27:11 2002
+++ mingetty-1.00/Makefile Mon Mar 4 15:27:34 2002
-@@ -1,6 +1,6 @@
+@@ -1,6 +1,7 @@
DESTDIR=
CC=gcc
-CFLAGS=-O2 -Wall -W -pipe -D_GNU_SOURCE
+CFLAGS=$(RPM_OPTS) -Wall -D_GNU_SOURCE
++LDFLAGS=$(RPM_OPTS)
MANDIR=/usr/share/man/man8
SBINDIR=/sbin
Index: mingetty.spec
===
RCS file: /cvs/pkgs/rpms/mingetty/devel/mingetty.spec,v
retrieving revision 1.19
diff -u -p -r1.19 mingetty.spec
--- mingetty.spec 8 Jan 2008 09:39:25 - 1.19
+++ mingetty.spec 10 Jan 2008 00:15:11 -
@@ -2,11 +2,12 @@ Summary: A compact getty program for vir
Name: mingetty
Version: 1.07
License: GPLv2+
-Release: 8%{?dist}
+Release: 9%{?dist}
Group: System Environment/Base
URL: http://sourceforge.net/projects/mingetty/
Source: mingetty-%{version}.tar.gz
-Patch: mingetty-1.00-opt.patch
+Patch0: mingetty-1.00-opt.patch
+Patch1: mingetty-1.07-loginpause.patch
BuildRoot: %{_tmppath}/%{name}-root
%description
@@ -15,8 +16,10 @@ use only on virtual consoles. Mingetty
lines (you should use the mgetty program in that case).
%prep
+rm -rf $RPM_BUILD_ROOT
%setup -q
-%patch -p1
+%patch0 -p1
+%patch1 -p1
%build
make RPM_OPTS=$RPM_OPT_FLAGS
@@ -38,6 +41,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man8/mingetty.*
%changelog
+* Wed Jan 09 2008 Bernardo Innocenti [EMAIL PROTECTED] - 1.07-9
+- add mingetty-1.07-loginpause.patch
+- improve mingetty-1.00-opt.patch to enable cross building on a 64bit host
+
* Tue
Re: mesh portal discovery
On Wed, 9 Jan 2008, Javier Cardona wrote: The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... You probably don't want that: a mesh point might have equal cost routes to several mesh portals. In that case you want some hysteresis: only change to a new MPP if it offers a big advantage over the current one. As long as it can communicate with it by hopping through the mesh, it will renew the existing lease and never discover a closer MPP/DHCP server This was the problem that prompted my original message on this thread. One way to do this would be to run a simple daemon that 1. Periodically sends traffic to the anycast address. If you want to use dhclient for this ( assuming it is patched as described here: http://www.cozybit.com/projects/mpp-utils/index.html#update ) you could send frames to the anycast address like this: # dhclient eth0 -1 -lf /dev/null -sf /bin/true 2. Compare the metric of the best mpp with the current mpp. This can be done via iwpriv fwt_list calls. 3. If the cost difference justifies it, wipe out the existing leases and re-discover # rm /var/lib/dhcp3/* ; dhclient eth0 you really don't want to change the IP of the laptop any more then you absolutly must, it's too likely to disrupt existing connections. as I understand it the mesh is (close to) continuously reconfiguring itself to find the most efficiant path across it. is the resulting information available to all of the MPP nodes? if it is you should be able to do something like the following. 1. on initial connection use the existing process to make a 'best guess' to find a DHCP server and get an IP address. 2. outbound packets use this IP address no matter which MPP the packets go through. 3. inbound packets go to the MPP that initially gave out the IP address. 3a. if that MPP determines that it is still the closest MPP to the end node, it sends the packet out normally. 3b. if the packet arrives at the MPP over a tunnel from another MPP, don't check the routing, just send it out over the mesh (avoids routing loops) 3c. if the MPP determines that another MPP is significantly closer to the end node, it tunnels the packet over to the closer MPP, which then sends it over the mesh to the end node. I think that step 3 can be tested without extensive code changes by useing hooks in iptables. Iptables has the ability to call out to userspace code as part of it's processing decision, if that userspace code reports that the end-node is closest to this MPP then it routes the packet normally, if it thinks that another MPP is closer, it returns somthing to indicate which remote node to use, and then the packet gets routed through a tunnel to that node (a simple GRE tunnel will do, we just need to encapsulate the packet) This approach requires that all of the MPP boxes know which one of them is closest to each end-node. If the current mesh structure does not provide this info to all nodes then an additional daemon would need to share this info (possibly over the same tunnels that are used to relay the traffic) I will say up front that I haven't done the iptables-userspace hooking in any of my projects, but this should be an easy way to prototype this before adding this type of routing to the kernel. This approach is safe, the worst case is that inbound packets take a longer path then optimal to get to the node (either they don't get re-routed when they should or they get re-routed when they shouldn't, either way they take more hops over the radio than nessasary). By not changing the IP address of the node it avoids breaking existing connections at the cost of an additional hop over wired networks Potential problems if you are doing NAT on the MPP then this approach won't work (becouse the outbound packets don't all go through the same MPP) if the different MPP boxes are on different Internet connections and there is egress filtering outside the MPP boxes, that filtering would need to allow the mesh IP's out through all MPP boxes. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. I sympathize with how overworked OLPC developers are. But a number of G1G1 systems are getting into the hands of articulate net-aware people. If they become disenchanted by the Legacy IP performance of the OLPC, what they say might result in hurting the whole project. I completely fail to see why we need the DHCP server ... I don't have wireless at home. First tried stopping NetManager, and manually setting the IP address. That worked, but screwed something up so I could not use the system in a cafe. So I restored the OLPC, and added a DHCP server in my home, __just__ for the OLPC. Effort that I had not anticipated needing to expend. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird WLAN problem after stupid upgrade attempt
Well, darnit. Looks like things are flaky. Here is the procedure and the results I just got. - Flash q2d07.rom test /wlan worked fine - Flash q2d08.rom (to verify that 08 is causing problems) test /wlan fails - device not found - Flash q2d08.rom (because I wanted 07 and mistyped the filename) - Flash q2d07.rom test /wlan fails - device not found - Pull battery and AC, wait 20 seconds test /wlan fails - device not found - Flash q2d07.rom again test /wlan fails - device not found test /usb - shows port 0 in use, same as on my working machine. This is with no USB sticks connected. When a USB stick is connected, then ports 0 and 1 are in use. So now that test /wlan is failing with '07, that encourages me to believe a simple hardware issue is occurring. Although the WLAN card is a USB device, I'm assuming it is surface mounted and there isn't any sort of physical connection that could have shaken loose is there? I'm not opposed to the use of a screwdriver, but I haven't bothered yet since I doubt that I could do anything. (-: Tom ;-) On Jan 9, 2008, at 4:27 PM, Mitch Bradley wrote: If you revert to Q2D07, does test /wlan work again? Q2D07 and Q2D08 have different versions of the wlan firmware wad. Perhaps there is something about your wlan hardware that works with the wlan firmware image in Q2D07, but not with the one in Q2D08 and not with whichever version is in your OS version. That is one of the only two hypotheses that come to mind. The other on is the possibility that there is something flaky about the onboard USB connection, so that the device sometimes enumerates and sometimes doesn't, depending on subtle factors. Tom Seago wrote: I've updated to the Q2D08 firmware now. Whereas the '07 firmware seemed to run the test /wlan ok, but the wlan card wasn't visible to the regular OS, now when I run the same command on the '08 firmware I get ok test /wlan Device /wlan not found. ok So what's the verdict. Do folks think I should RMA this thing? It seems like it got busted merely via software - which one would normally not expect to be possible. (-: Tom ;-) On Jan 6, 2008, at 12:56 AM, Tom Seago wrote: Hi Mitch. I got my developer key and ran test /wlan at the ofw prompt. That seemed to work! At least, it scrolled a fairly large amount of info up the screen which appeared to be the stats of various visible wifi networks. However, all my problems where the OS can't see the card remain. It makes me happy that this appears to be software not hardware. It still confuses me how I managed to get into this bizarre situation though. Is there a way to do any more complete of a device wipe beyond the normal reflashing procedure using the signed build from a usb stick? I appreciate your help. I hope we can figure out what's up with this thing. (-: Tom ;-) On Jan 4, 2008, at 10:22 AM, Mitch Bradley wrote: Tom Seago wrote: ... Another thing I have done is run the POST diagnostics by holding the left rocker button during boot. I did this on both machines at the same time to diff the results. Both say that usb port 0 is in use - good. But the working machine did scroll some wlan diagnostic information up the screen at the end of the the video tests that the broken machine did not do. The broken machine did not report an error - but it clearly did not run the same wlan test. Chris Ball wrote: Hi Tom, Once you have your developer key, please run: ok test /wlan If that fails too, it should be clear that we need to RMA and replace your laptop. Thanks! The POST diags that Tom ran include the test /wlan step. That diagnostic info that scrolled by is a dump of the access point scan info. It happens just before the touchpad test. My recommendations: a) Remove all power - AC and battery - for a few seconds to reset the wireless really well, then reboot and try the POST diags again. b) If that doesn't fix it, email me when you get your developer key and I'll work with you on IRC to see if we can learn more about the failure details. Mitch Bradley ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008, at 6:32 PM, [EMAIL PROTECTED] wrote: On Wed, 9 Jan 2008, John Watlington wrote: Sounds like you are volunteering to write that code. We need it by early next week. Yes, mobile IPv6 is one of our long-term solution possibilities. two things. 1. I didn't realize that participation wasn't desired except by people volunterring to write the code (the discussion sounded like people were trying to figure out what to do) 2. while I referred to mobile IP, the solution that I then outlined is not that complete. do you want me to shut up until I have completed code to present? or do you want people discussing options and trying to figure out a strategy that will work? Sorry about the snap, but you have to realize that I am currently the developer and QA department for the school server, and it isn't even my current job. And I really do need the answer implemented over the next week... Some handwaving about the best way to do it from the peanut gallery is fine, but don't expect to be listened to unless you can point to existing software or are willing to help implement the solution. We don't have infinite (or even sufficient) resources, nor the time for development and testing of complex solutions. I don't understand your dislike of changing IP addresses. My current laptop does it multiple times a day just fine, and it should only happen when a student is moving from one place to another (as long as Javier's comments about avoiding flapping are heeded). We have a presence service which provides a way for P2P applications to find one another, even after the IP changes. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote: Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. I sympathize with how overworked OLPC developers are. But a number of G1G1 systems are getting into the hands of articulate net-aware people. If they become disenchanted by the Legacy IP performance of the OLPC, what they say might result in hurting the whole project. You misunderstood our local IPv6 evangelist, he wasn't proposing to disable IPv4 on the laptop, just not to support it on the school server mesh. Given that all mesh capable devices will support IPv6, he's probably got a point. Here is my take-home summary of this thread: Short term solution is to turn off IPv6 on the mesh, and tell kids that if their network performance degrades, they should click on the circle again which will trigger an IPv4 DHCP discovery of the nearest MPP. Long term solution is probably to move to IPv6 only, using a user space agent to decide which RAs to listen to. This user space agent can implement Javier's suggestion to avoid flapping between MPPs. Mobile IPv6 would be frosting on the cake, but doesn't help with the primary problem of MPP selection. Thanks, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1525
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1525/ -sugar.i386 0:0.75.6-1 +sugar.i386 0:0.75.7-1 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird WLAN problem after stupid upgrade attempt
Tom, I would RMA the unit, going through Adam Holt instead of the normal process. We want to see this unit ourselves before sending it back to the manufacturer, as we haven't seen this problem in the past. The WLAN is a separate module, surface mounted to the motherboard. There have been occasional cases in the past where insufficient paste was present to properly solder it down, but they were caught in board level testing before assembly, and haven't been seen on mass production units. Given the lead-free soldering process we are using, solder cracks are also a possibility. If you decide to take a look yourself, all you need is one #1 phillips head screwdriver. I wouldn't even disconnect the LCD, just move it enough to get to the four screws holding on the back cover located behind it. A total of twelve screws need to be removed to get to the motherboard. Cheers, wad On Jan 9, 2008, at 9:13 PM, Tom Seago wrote: Well, darnit. Looks like things are flaky. Here is the procedure and the results I just got. - Flash q2d07.rom test /wlan worked fine - Flash q2d08.rom (to verify that 08 is causing problems) test /wlan fails - device not found - Flash q2d08.rom (because I wanted 07 and mistyped the filename) - Flash q2d07.rom test /wlan fails - device not found - Pull battery and AC, wait 20 seconds test /wlan fails - device not found - Flash q2d07.rom again test /wlan fails - device not found test /usb - shows port 0 in use, same as on my working machine. This is with no USB sticks connected. When a USB stick is connected, then ports 0 and 1 are in use. So now that test /wlan is failing with '07, that encourages me to believe a simple hardware issue is occurring. Although the WLAN card is a USB device, I'm assuming it is surface mounted and there isn't any sort of physical connection that could have shaken loose is there? I'm not opposed to the use of a screwdriver, but I haven't bothered yet since I doubt that I could do anything. (-: Tom ;-) On Jan 9, 2008, at 4:27 PM, Mitch Bradley wrote: If you revert to Q2D07, does test /wlan work again? Q2D07 and Q2D08 have different versions of the wlan firmware wad. Perhaps there is something about your wlan hardware that works with the wlan firmware image in Q2D07, but not with the one in Q2D08 and not with whichever version is in your OS version. That is one of the only two hypotheses that come to mind. The other on is the possibility that there is something flaky about the onboard USB connection, so that the device sometimes enumerates and sometimes doesn't, depending on subtle factors. Tom Seago wrote: I've updated to the Q2D08 firmware now. Whereas the '07 firmware seemed to run the test /wlan ok, but the wlan card wasn't visible to the regular OS, now when I run the same command on the '08 firmware I get ok test /wlan Device /wlan not found. ok So what's the verdict. Do folks think I should RMA this thing? It seems like it got busted merely via software - which one would normally not expect to be possible. (-: Tom ;-) On Jan 6, 2008, at 12:56 AM, Tom Seago wrote: Hi Mitch. I got my developer key and ran test /wlan at the ofw prompt. That seemed to work! At least, it scrolled a fairly large amount of info up the screen which appeared to be the stats of various visible wifi networks. However, all my problems where the OS can't see the card remain. It makes me happy that this appears to be software not hardware. It still confuses me how I managed to get into this bizarre situation though. Is there a way to do any more complete of a device wipe beyond the normal reflashing procedure using the signed build from a usb stick? I appreciate your help. I hope we can figure out what's up with this thing. (-: Tom ;-) On Jan 4, 2008, at 10:22 AM, Mitch Bradley wrote: Tom Seago wrote: ... Another thing I have done is run the POST diagnostics by holding the left rocker button during boot. I did this on both machines at the same time to diff the results. Both say that usb port 0 is in use - good. But the working machine did scroll some wlan diagnostic information up the screen at the end of the the video tests that the broken machine did not do. The broken machine did not report an error - but it clearly did not run the same wlan test. Chris Ball wrote: Hi Tom, Once you have your developer key, please run: ok test /wlan If that fails too, it should be clear that we need to RMA and replace your laptop. Thanks! The POST diags that Tom ran include the test /wlan step. That diagnostic info that scrolled by is a dump of the access point scan info. It happens just before the touchpad test. My recommendations: a) Remove all power - AC and battery - for a few seconds to
Re: Weird WLAN problem after stupid upgrade attempt
On Wed, 2008-01-09 at 22:50 -0500, John Watlington wrote: Given the lead-free soldering process we are using, solder cracks are also a possibility. Or tin whiskers? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
Jake Beard wrote: Hopefully, later this year we'll see a completely open Java, and then see Java on the XO. Flash is terrible. If it were possible, I'd prefer to see an all-Java solution. Sorry, but java sucks rocks, and although I dislike flash, I think it's a better solution for just streaming video. The several years I worked with Java was a nightmare of bloated code and poor performance. - rob - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
[EMAIL PROTECTED] wrote: We really need a open project to do patent analysis of this kind and determine which of these key patents (not just codecs, but also other important blocking patents) can be avoided, and which ones are too tied to the format to avoid. Perhaps the OLPC project would provide a good bit of motivation for people to do this type of work? As of last week, I've incorporated the Open Media Now! foundation to work on issues like this. Our current projects are Gnash and Cygnal (Cygnal being our media server). We hope to expand this as I raise funding to work on the political and legal aspects. Yes, good lawyers are expensive... I do believe that figuring out a clean and legal path through this minefield is very important for free software. - rob - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
Sebastien Adgnot wrote: However it seems quite difficult for us to encode our videos in Theora+Vorbis right now. I'm gonna talk to different people in the company to get their opinion and see what we can do. Ffm peg does a fair job at codec conversion. We use our friends at Lulu.tv to convert videos to free formats. In the meantime, I've heard of the Helix Media Player http://en.wikipedia.org/wiki/Helix_(project) for the OLPC project? It won't be of any help? No. It's not really useful, and the streaming codecs are not included, you still have to license the codecs anyway. The free version of helix is one of those brain damaged things that's purposely limited. - rob - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird WLAN problem after stupid upgrade attempt
On Jan 10, 2008, at 12:02 AM, Dan Krejsa wrote: On Wed, 2008-01-09 at 22:50 -0500, John Watlington wrote: Given the lead-free soldering process we are using, solder cracks are also a possibility. Or tin whiskers? How'd you know what my nightmares look like ? Yes, but I don't expect tin whiskers to form within a month of fabrication. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 679
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build679/ +iputils.i386 0:20070202-3.fc7 +libsysfs.i386 0:2.1.0-1.fc7 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/update.1-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
oom-killer during olpc-update?
Hi, I just tried olpc update from joyride-1500 to joyride-1525, on a G1G1 XO. I ran sudo olpc-update joyride-1500 from the terminal activity, and sometime during (or after) the irsync-dirty part of the update, X restarted. I thought the laptop was rebooting, but examining /var/log/messages later I saw that 'NetworkManager invoked oom-killer'. I've put the log at http://pastebin.ca/849111 . I had no other activities than terminal ( Journal) running at the time, and wasn't touching the laptop. Is this a known problem, or should I file a bug report? Any hints on recovery, or avoiding this in the future? I think I'll try 'olpc-update --usb'... - Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 9 Jan 2008, John Watlington wrote: On Jan 9, 2008, at 6:50 PM, Mikus Grinbergs wrote: Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. I sympathize with how overworked OLPC developers are. But a number of G1G1 systems are getting into the hands of articulate net-aware people. If they become disenchanted by the Legacy IP performance of the OLPC, what they say might result in hurting the whole project. You misunderstood our local IPv6 evangelist, he wasn't proposing to disable IPv4 on the laptop, just not to support it on the school server mesh. Given that all mesh capable devices will support IPv6, he's probably got a point. Here is my take-home summary of this thread: Short term solution is to turn off IPv6 on the mesh, and tell kids that if their network performance degrades, they should click on the circle again which will trigger an IPv4 DHCP discovery of the nearest MPP. Long term solution is probably to move to IPv6 only, using a user space agent to decide which RAs to listen to. This user space agent can implement Javier's suggestion to avoid flapping between MPPs. Mobile IPv6 would be frosting on the cake, but doesn't help with the primary problem of MPP selection. I'm trying to make sure I fully understand the problem it sounds as if you have a good mechanism in the mesh for the laptops to send packets to the nearest MPP the problem is that if they get an IP address from a MPP that is a long way away (either initially due to a problem or over time as the laptop moves more hops away from the MPP) the fact that reply packets will always go the the MPP that gave out the IP address (due to normal IP routing) results in a slow reply as these packets start taking longer to get from the MPP to the laptop. is this correct so far? this problem is further complicated by the IPv6 equivalent of DHCP makeing it more likely that the initial 'registration' with a MPP is less optimal. and to top things off, since the replies are typically larger then the requests (which is why people live with DSL that is only 512Kb outbound, but is 1.5Mb inbound) the additional delays on the inbound leg are significantly worse. I am makeing the assumption that the MPP machines know the wireless topology from each of their points of view i.e. not only do they know how to get to the wireless nodes from themselves (and how many hops away they are), but they also know this information for each of the other MPP nodes. If this assumption is not true currently, a daemon would need to be run to keep the MPP boxes in agreement over who is the best gateway to the laptop. If I am on track so far let me see if I can divide the resulting problem into three cases 1. the MPP boxes involved are 'owned' by seperate entites and may not know about each other over the wired network. 2. the MPP boxes involved are associated with each other, but may be two or more network hops away from each other, but all managed as part of the same set (with egress filters configured so that outbound traffic could come from any of the MPP boxes) 3. the MPP boxes involved with the mesh network are tightly coupled (all connected with a high-speed wire network on the same subnet (no routing between them, all on the same broadcase domain) addressing these one at a time. for #1 I can't think of any reasonable way to move a machine from talking to one MPP to another short of true mobile IP solutions. for #2 the basic approach is the same as LVS uses in tunneling mode see http://www.linuxvirtualserver.org/VS-IPTunneling.html for a diagram and explination This is basicly what I was suggesting earlier, don't worry about the outbound traffic, just bounce the inbound traffic to the closest node (via a tunnel) before sending it over the air. this chould be a matter of useing the existing LVS code and changing the server selection logic with something that is aware of the wireless topology. to avoid a routing loop where the packet gets bounced back and forth between MPP boxes, you should be able to set things up so that the load balancing is only done on packets coming in from the outside (I don't know if iptables can do this stock, but it should be a simple, if ugly hack to make packets arriving through a tunnel bypass the LVS code and get inserted just past it in the IP stack) the worst case with this model should be that some inbound packets get relayed to the wrong MPP and make more hops then they need to over the air. for #3 I am looking at other server load balancing options, specificly the clusterIP target available in iptables http://flaviostechnotalk.com/wordpress/index.php/2005/06/12/loadbalancer-less-clusters-on-linux what this does is to define an IP address that exists on all machine and uses a multicast MAC address, this forces the switch to send the packet to
