Re: DBus - Sessionbus rights
On Sun, 2008-04-06 at 15:32 -0400, Michael Stone wrote: On Sun, Apr 06, 2008 at 01:11:55AM -0400, Polychronis Ypodimatopoulos wrote: The SystemBus is used for communication between processes that belong to different users. By default, /etc/dbus-1/system.conf says ...Deny everything then punch holes Why do we forbid the default user (olpc) by default from advertising processes under a well known name? Simple inertia combined with the fact that the authors of most processes running as uid 500 have considered their software to be session software rather than system software. If you feel differently, please consider suggesting a policy that you think is a better fit for our dvision of responsibility. (Though take into account the fact that we are presently trying to get Sugar and its dependencies running on non-OLPC systems.) What's wrong with user processes making their presence known on SystemBus? My suspicion is that it's an anti-spoofing measure, but that's merely a guess. Have you considered asking on one of the dbus mailing lists? Luckily all mail with DBus in the header gets filtered into a single folder ;) Yes spoofing is the answer here (it is sort of like asking why can't users create applications that run from /usr/bin though not quite exact). If we allowed users to grab names on the system bus that aren't marked as allowed to be used by users they could spoof HAL, the datastore or even the bus itself. Since applications running as root also access these services it could be used as an exploit to gain root privileges. In any case the session bus is what you want to use to create services other apps (in the session) can use. I don't know if OLPC's security model allows you to write to the local autostart directory but if it did you could even use that facility. I would suggest OLPC however restrict names to the application's own namespace and reserve certain namespaces (like org.laptop) for signed bundles. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
On Mon, 2008-04-07 at 10:57 -0400, Polychronis Ypodimatopoulos wrote: John (J5) Palmieri wrote: Luckily all mail with DBus in the header gets filtered into a single folder ;) Yes spoofing is the answer here (it is sort of like asking why can't users create applications that run from /usr/bin though not quite exact). If we allowed users to grab names on the system bus that aren't marked as allowed to be used by users they could spoof HAL, the datastore or even the bus itself. Since applications running as root also access these services it could be used as an exploit to gain root privileges. This sounds to me like we should not allow the user to run a server on _any_ TCP port, because he may spoof an SSH/POP/DNS server. Instead, the solution was simply to not allow the user to run servers on ports lower than 1000. Even if we fixed this on the XO, my ubuntu distribution has the same security policy, so maybe a bug should be filed against DBus? Just because they are communications layers doesn't mean they have the same security profiles. This is not a bug. If you want some name to be able to be owned you need to add a security policy for it. If you want to take your analogy further, it is akin to having to punch holes in the firewall. You still need access to root to do that. In any case the session bus is what you want to use to create services other apps (in the session) can use. In my case, user processes need to have a two-way communication with a system process, like having a system process listening on a well-known port and user processes register themselves with the system process, stating on which port they are listening for data. The user processes need not necessarily use a well-known dbus name like 'org.laptop', but I could not publish a method (from a user process) on the system bus from an address like| :0-31.| I can't think of a reason to want a system process invoking methods on a user process. More likely you want the system process to send signal and have the user process listening for them. As long as the system process has a security profile to allow the user process to listen for those signals. You can send signals to specific unique names if you need to. I would suggest you run your system process with a little privileges as needed. BTW. you can't install system processes on the OLPC unless they get into a build or the user takes steps to install as root. I would encourage you to discuss your design on the list more to see if you can't figure out a better way to run your app as the user only. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
On Mon, 2008-04-07 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: John (J5) Palmieri wrote: I can't think of a reason to want a system process invoking methods on a user process. Well, in my case, the system process is the only one having access to the network and provides network connections and events to all user processes. Sending signals to user processes is a bad choice (although this is what I'm doing right now), because it breaks the privacy between user processes. All is not lost. User processes do not necessarily have to allocate a well known name, as long as it is possible to export a method from a numeric bus address. Is this possible? Example? No, this is part of the security profile. Signals can be sent to specific addresses though so as to not break privacy. That I would ask on the D-Bus list. I can't remember what the syntax for that is in python. As for getting network connections user processes should be able to do that. If you are in need of secure ports I would strongly recommend working with the core OLPC developers to make sure it isn't bypassing the security framework. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libglade?
On Mon, 2008-01-14 at 15:41 -0600, Jameson Chema Quinn wrote: I'm still noodling around, trying to settle on a good design for develop. It looks as if libglade would be nice to have. The interfaces it uses are loaded directly from XML, which makes them separate from the source code. I did a naive 'yum install libglade' and my XO pulled 100k for the library and about 3.5 MB (uncompressed) of dependencies. For our purposes, under .5MB of those dependencies are really needed. If, after rebuilding to remove dependencies on gnome-libs and the like, the whole thing came in at less than half a megabyte of uncompressed code, do people think it should be included in the base system? Obviously, the OLPC version would include all the sugar widgets... Use GtkBuilder instead. It is based off of libglade the biggest difference is instead of a widget tag there is an object tag. It also loads files a bit differently as you don't need to have top level windows like you do in LibGlade but there is no way to say load from a specific root in the xml tree so you end up having to split the file into different pieces depending on how you structure your UI. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 656
Its for Opera I think or perhaps for the old flash. A lot of closed source applications need it because they compile once for all Linux platforms they support meaning lowest common denominator. It might be that we are past that point but I am not entirely sure. On Thu, 2007-12-13 at 09:57 -0500, C. Scott Ananian wrote: On Dec 13, 2007 2:19 AM, Bernardo Innocenti [EMAIL PROTECTED] wrote: On 12/13/07 00:58, Build Announcer Script wrote: +compat-libstdc++-33.i386 0:3.2.3-61 Why do we even need this? I don't know, but it's explicitly listed in pilgrim as a package to install. joyride has had it, but due to the way that ship.2 was built, it did not. If no one on devel can remember why it was present, I can remove it from pilgrim. J5 added it on Mon Mar 26 18:39:45 2007 -0400 with the commit message, added compat-libstdc++-33. http://dev.laptop.org/git?p=users/cscott/pilgrim;a=commitdiff;h=6264353082f6542cbd4168ec5b7abea9a486d506 cc'ing J5; maybe he remembers why this was done? --scott -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Msoffice on xo
On Thu, 2007-11-15 at 20:10 -0600, [EMAIL PROTECTED] wrote: Would it be possible to set up an inexpensive data center in china, put an application server together, and serve windows xp and ms office (at the $3 educational pricing) Remember that is $3 per user , and then serve them through VNC on the xo, Yes it is possible treating it as a thin client, to address those in some countries who may feel it is important to have children learn ms office and windows for employment purposes? Schools should be teaching the concept of word processing not a specific word processor but that is as far as I will go with throwing tomatoes. or instead of a datacenter, make the school server an app server through Wine? Why not just serve up open office? Alternatively, possible to ask sun to adapt open office for xo? OO is way to big to run on the xo. AbiWord is the basis of the Write activity so it would be easy enough to run it on the xo. The big question to ask is if you have any experience with education in China or if this is just your perception of what China wants. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: project idea: Interactive-Sugar-Online-Simulation (ISOS)
On Thu, 2007-11-15 at 01:59 +0100, Christoph Derndorfer wrote: Hello, I just stumbled across a very interesting comment by Eduardo Montez over on OLPCnews.com (http://www.olpcnews.com/laptops/xo1/olpc_news_100_laptop_fundraising_drive.html): off topic: I just got an idea for showing people what Sugar can do. Some should put up an interactive web site where anyone can sign on for free, and all the people who are using it at any time would be the community and show up on the gui, connected through the server instead of the meshnetwork. That way people could experience the collaborative aspect of Sugar, which is its greatest innovation. I certainly think this is an outstanding idea, even though such an implementation is obviously anything but trivial. Such a virtual Interactive-Sugar-Online-Simulation (ISOS) could potentially act like one of those web-operating-systems that have become somewhat popular lately. It would basically allow for children who use a regular Windows PC to use at least some of the innovations and unique features that Sugar provides. So the requirement for being able to benefit from these outstanding developments would shift from need to have an X0 to need to have some computer with a browser and internet connectivity. What do you think? Best regards, Christoph Sounds great. Go ahead and implement it. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
list of rouge packages
Dennis, Here is a list of the rouge packages, with notes, not yet in the build system or needing update there. I gathered this from the trial-3 tmp repo so joyride may have more and newer packages and some of these may be obsolete. I am cc'ing the devel list so others can correct the list and add locations of the SRPMS. Avahi smcv is ontop of this owner: dcbw (Dan Williams) tmprepo: avahi-0.6.20-5.fc7.i386.rpm avahi-autoipd-0.6.20-5.fc7.i386.rpm avahi-compat-libdns_sd-0.6.20-5.fc7.i386.rpm avahi-dnsconfd-0.6.20-5.fc7.i386.rpm avahi-glib-0.6.20-5.fc7.i386.rpm avahi-tools-0.6.20-5.fc7.i386.rpm avahi-ui-0.6.20-5.fc7.i386.rpm bootanim Needs to be added to OLPC-2 though it may be a one-off that is replaced later down the road owner: cscott (C. Scott Ananian) tmprepo: bootanim-0.12-1.i386.rpm dbus-python http://dbus.freedesktop.org/releases/dbus-python/dbus-python-0.82.3.tar.gz needs to be pushed to F7 or branched for OLPC-2 owner: J5 (John (J5) Palmieri) tmprepo: dbus-python-0.82.1-2.fc7.i386.rpm etoys This is in review at https://bugzilla.redhat.com/show_bug.cgi?id=247984 and https://bugzilla.redhat.com/show_bug.cgi?id=247983 Issue involves refusal to sign CLA which might be resolved via an olpc-cla agreement. Solution for now might be to review the packages and have someone else get them into Fedora. Build manager also needs to keep ontop of olpc-cla to make sure it goes through if needed. owner: bertf(Bert Freudenberg) tmprepo: etoys-2.1.1664-1.noarch.rpm squeak-vm-3.9-11olpc5.i386.rpm gtksourceview2 This needs to get into the repo and forked for OLPC-2 (might be in F-8). It can't get into F7. owner: cjb (Chris Ball) tmprepo: gtksourceview2-1.90.3-3.olpc2.i386.rpm pygtksourceview-1.90.3-1.fc8.i386.rpm evince-olpc Should be merged into evince and pushed eventually. owner: marcopg (Marco Pesenti Gritti) tmprepo: evince-olpc-0.3-1.i386.rpm fonts-thai-ttf Need to get this into Fedora. Talk to Bernie because he pushed through the other fonts. Owner: bernie (Bernardo Innocenti) tmprepo: fonts-thai-ttf-0.4.4-1olpc1.2.noarch.rpm libabiword This is a library UI split of abiword which is the future of abiword development. Marc has Fedora dev access and said he wants to get this in though it most certainly can't go into F7. F8 is frozen so if it isn't there now it needs to get into OLPC-2. It would be nice if it is parallel installable with monolithic abi. Owner: uwog(Marc Maurer) tmprepo: libabiword-2.5.2.svn20070910-1.i386.rpm libabiword-plugins-2.5.2.svn20070910-1.i386.rpm libertas-usb8388-firmware This needs to be pushed in all Fedoras. There is still issues with how upstream names their tarballs which tend to change from release to release. Legal has already vetted the license and the Fedora board has accepted it. Owner: J5 (John (J5) Palmieri) tmprepo: libertas-usb8388-firmware-5.110.19.p0-1.olpc1.noarch.rpm olpcrd As is it would never get past Fedora package review. Need to work with C Scott to figure out what we should do here. One option is to have pilgrim build this since we want to eventually run the system python from here for memory saving reasons. owner: cscott (C. Scott Ananian) tmprepo: olpcrd-0.32-1.20071018git072ad8e70b.i386.rpm olpccontents I'm not sure exactly what is in this and how it is different from olpc-utils or olpc-logos. C. Scott uploaded it so he would be good to talk to about if this is something that can be merged into an existing package or we need to create a new package. owner: cscott (C. Scott Ananian) tmprepo: olpccontents-1.0-1.20070925git30cbb9db3b.i386.rpm pyvserver In review at https://bugzilla.redhat.com/show_bug.cgi?id=250463 pyvserver-1.0-0.3.fc7.noarch.rpm - almost done but needs to be pushed that extra mile and then built into OLPC-2 owner: mstone (Michael Stone) tmprepo: pyvserver-1.0-0.3.fc7.noarch.rpm rainbow Already in Fedora but needs pyvserver to build newer version. owner: mstone (Michael Stone) tmprepo: rainbow-0.6.6-1.fc7.noarch.rpm X components These need to be forked. Also Bernie eventually wants to get the newer X in though timing needs to be right for that. owner: bernie (Bernardo Innocenti) tmprepo: xorg-x11-drv-evdev-1.1.5-1.olpc2.i386.rpm xkeyboard-config-1.0-0.11.20070829cvs.olpc2.noarch.rpm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: list of rouge packages
On Mon, 2007-10-29 at 20:23 +0100, Marco Pesenti Gritti wrote: On 10/29/07, John (J5) Palmieri [EMAIL PROTECTED] wrote: Avahi smcv is ontop of this owner: dcbw (Dan Williams) tmprepo: avahi-0.6.20-5.fc7.i386.rpm avahi-autoipd-0.6.20-5.fc7.i386.rpm avahi-compat-libdns_sd-0.6.20-5.fc7.i386.rpm avahi-dnsconfd-0.6.20-5.fc7.i386.rpm avahi-glib-0.6.20-5.fc7.i386.rpm avahi-tools-0.6.20-5.fc7.i386.rpm avahi-ui-0.6.20-5.fc7.i386.rpm This is a F-7 build which has not yet been pushed as an update. It's currently in my public_rpms. Maybe we can just tag this one once we setup a branch for killjoy? dbus-python http://dbus.freedesktop.org/releases/dbus-python/dbus-python-0.82.3.tar.gz needs to be pushed to F7 or branched for OLPC-2 owner: J5 (John (J5) Palmieri) tmprepo: dbus-python-0.82.1-2.fc7.i386.rpm Same as above. There is a newer version of this upstream that should go in. That is the only reason I haven't pushed this in F-7. I should do this and push it. Doing it now. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New build 620
Not yet, next one will. On Fri, 2007-10-26 at 14:31 -0400, C. Scott Ananian wrote: On 10/26/07, Build Announcer Script [EMAIL PROTECTED] wrote: Build 620 ChangeLog Base OS: - kernel - 2.6.22 - 20071025.2.olpc.bbb713f3c2b591f.i586.rpm * OLPC: add C2 and C3 board support I believe this kernel also has a fix for a suspend/resume bug wad cjb found while in China. --scott -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New build 620
ChangeLog updated On Fri, 2007-10-26 at 17:33 -0400, Andres Salomon wrote: EHCI (usb) workaround for an irq suspend race ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: glibc bugs affecting Ethiopian
On Mon, 2007-10-08 at 14:46 -0400, Bernardo Innocenti wrote: John, to enable the am_ET locale, we need a few glibc bugfixes from F8. Ulrich Drepper, the glibc maintainer, says a backport would be quite invasive and highly recommends updating instead. Additionally, until now glibc wasn't forked in OLPC-2. I installed 2.6.90-17 and everything appears to work, but of course it would need more testing. So I propose we update glibc post Trial-3. If that's not acceptable, the alternatives I see are: 1) attempt a backport and fork glibc. That would give us a good excuse to enable the Geode optimizations too. 2) Leave Ethiopian as an unsopported language in FD1.0 and tell people to follow the procedure on the wiki to add it manuall This is a business decision. How likely is a Ethiopian sale in the short term? Does it pay right now to get distracted by Ethiopian support (other than planning for the future) or concentrate more on the places we are shipping? Talk to Uli and find out if he knows of any interactions with other libraries. If the risk is low and the benefits high then go for it. However for FRS 1.0 I suspect it would be best to not make this change. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: glibc bugs affecting Ethiopian
On Mon, 2007-10-08 at 14:58 -0400, Walter Bender wrote: How likely is a Ethiopian sale in the short term? Ethiopia is going to be one of the launch countries, unless negotiations between the Prodi government and Ethiopia somehow go awry. -walter In which case the decision is made and you should build and heavily test using the F8 glibc if there is no other way to fix the issues with Ethiopian support. On 10/8/07, John (J5) Palmieri [EMAIL PROTECTED] wrote: On Mon, 2007-10-08 at 14:46 -0400, Bernardo Innocenti wrote: John, to enable the am_ET locale, we need a few glibc bugfixes from F8. Ulrich Drepper, the glibc maintainer, says a backport would be quite invasive and highly recommends updating instead. Additionally, until now glibc wasn't forked in OLPC-2. I installed 2.6.90-17 and everything appears to work, but of course it would need more testing. So I propose we update glibc post Trial-3. If that's not acceptable, the alternatives I see are: 1) attempt a backport and fork glibc. That would give us a good excuse to enable the Geode optimizations too. 2) Leave Ethiopian as an unsopported language in FD1.0 and tell people to follow the procedure on the wiki to add it manuall This is a business decision. How likely is a Ethiopian sale in the short term? Does it pay right now to get distracted by Ethiopian support (other than planning for the future) or concentrate more on the places we are shipping? Talk to Uli and find out if he knows of any interactions with other libraries. If the risk is low and the benefits high then go for it. However for FRS 1.0 I suspect it would be best to not make this change. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Build 542.3 out with local fixes
Please test as this will become the next stable build. Build 542.3 fixes sugar so that it installed the translation files and also fixes a Journal bug for the Spanish locale. http://olpc.download.redhat.com/olpc/streams/development/build542.3/ -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Auto-building emulator downloads
On Sun, 2007-08-26 at 20:05 -0400, Mike C. Fletcher wrote: Ivan Krstić wrote: On Aug 26, 2007, at 7:07 PM, Mike C. Fletcher wrote: Still, building them somewhere not behind a cable modem would be a good idea. Right, I assumed giving you a shell on dev would let you convert the images right on that machine. Are there other requirements? There's a few: * Qemu installation (for the qemu-img tool that converts to VMWare disks) * VirtualBox installation (for the vboxmanage tool that converts to VirtualBox disks) No need for this as VB can run VMWare disk fine. * The overlay stuff also requires: o ability to mount a loopback partition (to modify the ext3 image with the overlay) o ability to do an rsync over top of the mounted image (requires super-user access AFAICS) The first two might be something you could run on dev (though I'd be hesitant to increase your attack surface for the machine that way), but the overlay operations are not the kind of thing you want running on a publicly accessible server AFAICS, just too many security issues, really. You'd want to run it on an old box somewhere with nothing sensitive on it and then push the images up to dev I would think. I already have scripts in pilgrim to do a sdk build which outputs a vmware image with vmware and VB meta files. Let's build on that and I can do sdk builds along with regular builds. I just need to know what people think should be in a development image. BTW the build servers run as root and have qemu on them. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Repos branched for trial-3
There are now two branches for the fedora repos, dist-olpc2 and dist-olpc2-trial3. Everyone still build in olpc2 but must request packages to be moved into olpc2-trial3 in order to get it into the build. Please file a bug with the name of the package, version and release along with a detailed changelog. Only bugfixes can get in as feature freeze was today. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: .xo bundles (was Re: #1803 HIGH Trial-2: Add Chat activity to builds)
On Tue, 2007-07-03 at 23:47 +0200, Bert Freudenberg wrote: Comment (by J5): Replying to [comment:4 bert]: Replying to [comment:3 J5]: This was generated incorrectly. First the version should be -9 second the activity should be Chat-9.xo. It looks like it was simply zipped up instead of using the packaging tools. Not sure what else is wrong, but simply zipping up is surely as valid as using whatever tools there are, right? No, right now it works but in the future there is no guarantee as we may do post processing. Also python setup.py dist creates a clean package without any of the stray development files (such as MacOS resource files) getting packaged up. Such garbage should not be included obviously. But I'd much prefer if bundles stay simple zip files without added magic. What kind of post processing do you imagine that could not be easily done manually? Give people a generic mechanism and they do crazy things. The fact that it is a zip archive is purely coincidental. What defines an activity bundle is not the compression format but the contents within. In order to keep that integrity we have tools which do various checks to make sure the bundle contents are correct. They also take the guesswork away from naming and may in the future have the ability to automatically sign the package and take sha1 snapshots of all the files so it can reassemble the package for installation on another XO. All this can be done by hand but humans make mistakes (such as forgetting a step) which are easily caught by scripts. In autotools land we could simply just bundle up a CVS repository and call it a release but often this causes the application to not compile correctly which is why we have make dist and make dist-check. The tools used to create bundles are there for similar purposes. It allows you to do development within the bundle itself but release a clean version for others to use. BTW We now have an official registered mime type vnd.olpc-sugar which specifies XO as the magic key to identify the mime type. At some point the PK in the zip header will change to XO. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: .xo bundles (was Re: #1803 HIGH Trial-2: Add Chat activity to builds)
On Wed, 2007-07-04 at 20:39 +0200, Tomeu Vizoso wrote: On Wed, 2007-07-04 at 14:18 -0400, John (J5) Palmieri wrote: BTW We now have an official registered mime type vnd.olpc-sugar which specifies XO as the magic key to identify the mime type. At some point the PK in the zip header will change to XO. Hmm, I was thinking about doing something similar to what OpenDocument does by storing a mimetype file uncompressed on the root of the archive. In this way we can sniff the mime type while retaining full compatibility with zip files. Also, we can sniff for different kinds of bundles, if we reserve vnd.olpc-sugar for activity bundles. That is fine but the magic bit makes it easier for others and doesn't remove compatibility from zip tools. They just spit out a warning. BTW in fedora .ods files are opening up as zip archive. That is clearly wrong. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
Looking into it, most likely a NetworkManager issue. On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) John, Can we get a changelog with each build now? Between the changelog and the release information that can be provided on the 'Test Group Release Notes', we will be providing some good info for those who want to use the latest build. Regards, Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) John, Can we get a changelog with each build now? Between the changelog and the release information that can be provided on the 'Test Group Release Notes', we will be providing some good info for those who want to use the latest build. Regards, Kim Ok, starting to do ChangeLogs with each build. I think I found the networking issue which I will fix in the next build. For now if you want you can log into root at a terminal and type chmod +x /etc/NetworkManager/callouts/* That should fix things. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ivan's XO Field Upgrade Proposal
On Tue, 2007-06-26 at 12:32 -0400, Dan Williams wrote: On Tue, 2007-06-26 at 12:16 -0400, C. Scott Ananian wrote: On 6/26/07, Dan Williams [EMAIL PROTECTED] wrote: Downside of this is, as Alex pointed out, it'll load the mesh a _lot_ more than XO-XO updates. Not necessarily. Rsync is pretty efficient: we're still basically distributing just (blockwise) diffs. And we can always do XO-to-XO later: the important thing is to get a rock-solid basis. The selling point (to me) is the simplicity. Like I said: its the simplest thing that works. I'm not arguing simplicity; just that we have to be aware of the implications of having lots of XOs pulling from the server with some overlap with this method, but we don't with XO-XO. We just have to make the tradeoffs clear, and understand them. Dan I can do some benchmarks if people actually need to see numbers. --scott We Also have to remember the countries want control over when the boxes update. At least that was the impression I got at the country meetings. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why pilgrim does not support indic language
On Tue, 2007-06-26 at 10:08 +0530, sachin Tawniya wrote: Hi all, I have tried pilgrim with fedora and olpc development repo. Also I added gnome-session and scim things with some indic language support. I got ISO image with gnome and scim activated things. I can operate in common indic language like Hindi and can use it with terminal, text editor etc... Issue with me is, when I want my desktop should come in local language, it's not providing any indic language selection menu. Take a example of Indic-Hindi. I have installed m17n-dn-hindi, fonts-hindi etc.. While login if I select change language option, it doesn't provide option for hindi (Indic Language) Can any one give me some reference over it or any suggestions for supporting/enabling Indic Language in OLPC ISO. Any suggestions will be appreciated. First, Sugar and activities need to be translated. Please see http://wiki.laptop.org/go/Activity_Translations Second, since we work off dedicated hardware we can tell what language the device is laid out for. Please look at /etc/init.d/olpc-configure to see how we configure languages. Third, no one has put work in creating a language selection menu though I think we do need some sort of place to make it easy to override the default settings. Patches welcomed. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Getting problem in importing repomd.xml
On Thu, 2007-06-21 at 10:08 -0400, Bernardo Innocenti wrote: sachin Tawniya wrote: Thank you for informing. I was in confusion about, weather I am doing some thing wrong or I am not able to access to that network. With my local repo data, I am having some issues with starting udev. I'm sorry, I have no idea. The local build expert is J5. Cc'ing him. If you have any idea over it, can you please guide me, what am I suppose to do? I am getting error like UDEVD ( some msg and then add the rule in /etc/udev/00- cdlable.rule ) I am totally confused what to do. Is there any modification I am suppose to do with mayflower script or else where other files in pilgrim regards, Sachin I'm confused. What does a local repo have to do with udev? Please clarify the problem you are experiencing and what steps you have been using to get there. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
