Enable security in Update.1 builds
Hello, we need to enable security in the Update.1 images, since the plan is to ship with it enabled. Looks like it's turned off in pilgrim at the moment. 463 echo - turning off security by default 464 rm -f $INSTALL_ROOT/etc/olpc-security Dennis, we are planning to request approval for a few more packages this afternoon, it would be good to make a new build with all of this in. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updated GStreamer RPMs
On 12/14/07 23:30, Chris Ball wrote: Hi, We're planning to rebase on Fedora 8 for Update 2, but it's good to be able to preview these ahead of time. Has this been proposed somewhere? I don't think I agree with it. I don't disagree strongly, but just enough that I'll stop someone from talking about it as if it's already been decided. ;-) http://lists.laptop.org/pipermail/devel/2007-December/008328.html (My reason for disagreeing is the standard progress vs. support dichotomy. I'd rather we kept the base OS as a known quantity but worked really hard on things like performance.) I'm also not strongly biased. The reason I'm in favor of upgrading is that it would help us cleaning up a number of packages newer than F7 that we were already carrying. Moreover, some experimentation shows that it would be somewhat painless. The only problem I experienced was the one I mentioned with hal. -- \___/ |___| 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
Update.1 builds
The location of the Update.1 builds has changed: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/ I'm not sure if it's the final location but it would be to update the Changelog to point to it. http://dev.laptop.org/~bert/update.1-pkgs.html Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 builds
On Dec 15, 2007 7:41 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: The location of the Update.1 builds has changed: http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/ I'm not sure if it's the final location but it would be to update the Changelog to point to it. http://dev.laptop.org/~bert/update.1-pkgs.html Almost the final location. As documented in trac bug #5279, ultimately all builds will be transferred to download.laptop.org after passing an automated test. So pilgrim is the 'final location' until we get the automated test infrastructure running, then everything will move to its real final home on download.laptop.org. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process ( was Re: Update.1 schedule and code freeze...)
On Dec 15, 2007 3:14 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Dec 15, 2007 7:35 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Dec 14, 2007 11:01 PM, Jim Gettys [EMAIL PROTECTED] wrote: Declaring code freeze for Update.1 today would not see a rational resolution of these issue. As promised, this is a release that is driven by completion of content, rather than driven by necessity of hardware schedules. On the Sugar side, the main reason of the delay is that dealing with the various release process steps has been a lot more painful then it needs to be. We wasted a *lot* of time there. My personal feeling is that we created update.1 too soon. IMO development should have been occurring in the joyride builds up until code freeze (yesterday, or a week from yesterday). There's no reason to fork update.1 just for string freezes; translation can still occur in the joyride branch. Code freeze is the point at which we should fork the builds. I agree that branching should happen at code freeze. But then ApprovalForUpdate should only be introduced *after* the freeze and update.X should be branched from joyride. Otherwise ApprovalForUpdate tickets accumulate for weeks, until we branch, and then we get to cleanup the mess. We already have an approval step in place (Update.1? - target Update.1) and IMO that's enough for the development period. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process ( was Re: Update.1 schedule and code freeze...)
On Dec 15, 2007 3:54 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: C. Scott Ananian wrote: My personal feeling is that we created update.1 too soon. IMO development should have been occurring in the joyride builds up until code freeze (yesterday, or a week from yesterday). There's no reason to fork update.1 just for string freezes; translation can still occur in the joyride branch. Code freeze is the point at which we should fork the builds. I approve of delaying code freeze slightly in the interest of making the freeze firmer when it occurs. +1 The moment we create a release branch and start cherry picking packages for inclusion one by one, we effectively are already in some sort of code freeze. Many centralized projects I've worked for tend to have a 2/3 development and 1/3 code freeze time share in each release cycle, which seem like a good compromise for a lightweight development process that still allows enough time for stabilization. Moreover, I was very confused by the fact that we branched Update.1 from Ship.2 rather than from Joyride, which I still considered our development trunk. Until a few days ago, I've been working under the assumption that all the work I had done in Joyride before Dec 15 would implicitly show up in Update.1. Exactly. Can we get this right for Update.2? :) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Enable security in Update.1 builds
Scott, The Roadmap lists activity isolation as a release criterion for Update.1. Was there a public announcement that I missed explaining why activity isolation was ever turned off? Thanks, Michael On Sat, Dec 15, 2007 at 12:31:43PM +0100, Marco Pesenti Gritti wrote: Hello, we need to enable security in the Update.1 images, since the plan is to ship with it enabled. Looks like it's turned off in pilgrim at the moment. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process ( was Re: Update.1 schedule and code freeze...)
On Dec 15, 2007 10:26 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Dec 15, 2007 3:54 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Moreover, I was very confused by the fact that we branched Update.1 from Ship.2 rather than from Joyride, which I still considered our development trunk. Until a few days ago, I've been working under the assumption that all the work I had done in Joyride before Dec 15 would implicitly show up in Update.1. Exactly. Can we get this right for Update.2? :) I believe this has been a source of a lot of confusion, and one which I keep running out of time to ensure we discuss at our Tuesday meetings. I'm speaking for jg here, and I might be wrong, but my understanding is that JG wanted to ensure he could keep tabs on exactly what was changing between ship.2 and update.1, but that update.1 will be (eventually) substantially the same as joyride at the time of code freeze. We'll pull a diff and make sure that if any joyride-at-time-of-code-freeze package is *not* in update.1, we know exactly why. We have had differences of opinion here, so I probably shouldn't try to elaborate further. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updated GStreamer RPMs
Yes. We need to discuss this in detail. Let's get over the Update.1 hurdle and regroup, hopefully with better mechanisms for discussion and vetting. -walter On Dec 15, 2007 7:46 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Dec 15, 2007 1:12 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: Moreover, some experimentation shows that it would be somewhat painless. The only problem I experienced was the one I mentioned with hal. I don't really think your testing proves much in this regard. You only really figure out what breaks when you start doing serious testing. I'd like to see stronger arguments in favor of the upgrade, before deciding to take the risks and the costs. Marco ___ Devel mailing list 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
Re: Enable security in Update.1 builds
Hi, I've attempted to remove the ship.2-specific patches from pilgrim's update.1 branch and synchronize it with joyride. That should enable security, but it looks like ohm might not be started until cjb addresses trac #5509 (see also trac #5510 and 5511). #5509's been done since before Ship.2 was released, so all clear from me. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity Icon design question
Hi all, I am thinking about using 9 different icons for the PlayGo Activity. The icon will reflect the number of handicap stones that the black player starts with. The icon will have from 1 to 9 black dots on the board star points. This could be used to offer people games in the neighborhood so that the joining person knows the limit if the handicap stones the initiator will offer. Two questions: 1. Is it possible for sugar to set and propagate a change in the activity icon? 2. Is the concept of a morphing activity icon withing the HIG? - Gerard ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process
On Dec 15, 2007 5:27 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: I've started building my own images a few weeks ago and found that it is not at all difficult. All I had to do was really cloning the pilgrim repo and changing the build name from joyride to xtest. A build generally takes 10 minutes on my desktop PC. My build system is x86_64 and Fedora 8. Anything that would run a mock chroot would probably work. Care to put quick instructions on the wiki? This is something I wanted to do several times, but never felt to invest the time to learn how. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC News 2007-12-15
1. Kuala Lumpur: Matt Keller attended the Global Knowledge Conference this past week; the conference brought together over 2000 people from around the world. Matt was part of a BBC World debate on technology and the developing world generally, and the XO specifically. While most of the panelists were somewhat critical of olpc and OLPC, the audience was very much in favor. The debate will be broadcast on BBC World on five different occasions in January. 2. Montevideo: Michail Bletsas attended a technical meeting organized by LATU to discuss the technical requirements for the connectivity infrastructure of the schools in the Colonia and Durazno districts: the next (after Florida) to get XO laptops after school commences again in March. The main purpose of the meeting was to discuss the main requirements of the RFP that is going to be issued in the next few days. Michail also spent several hours at LATU discussing connectivity details with the Ceibal team and left Uruguay impressed with both the enthusiasm of the people involved in the project as well as their accomplishments. 3. Cambridge: The learning team (Carla Gomez Munroy, Ed Baafi, Julian Daily, Mel King, and David Cavallo) conducted the second monthly workshop for countries. Attending were teams from Mongolia, Panama, the city of Birmingham, Alabama, the US State Department for schools in Iraq, and Calestus Juma as both a contributor and looking towards Kenya and East Africa. The week went extremely well and most encouraging is how participants are turning themselves into a strong network for advancing learning in their countries. Special thanks also to Erik Blankinship, Bakhtiar Mikhak, Ben Schwartz, and Shannon Sullivan for demoing their activities on the XO during an afternoon open house. The youth from the Learn to Teach: Teach to Learn program working with Ed and Mel once again presented their work and convincingly demonstrated the tremendous benefits for both the teachers and learners when kids teach other kids. 4. Schedules: We did not quite get to code freeze today and will need a few more days to get the most important bugs fixed for the Update1 release. (As Jim Gettys pointed out, the Update.1 release is driven by completion of content, rather than driven by necessity of hardware schedules.) We will start creating candidate releases next week. Please see http://dev.laptop.org/roadmap for the list of bugs being addressed and to look ahead to what we would like to go into Update.2. Testing should be on-going on the Update.1 (stabilizing for release in mid-January) and Joyride streams (mainline, features/fixes for Update.2). There is a discussion on the devel list about how to improve the build process. Please feel free to make additional suggestions: we want to the process to be more efficient for everyone. 5. Support Issues: A problem was found in Uruguay where where laptops were losing the ability to display their Journal contents and launch activities. Ivan Krstić did some heroic emergency debugging, created a patch, and helped them to distribute a fix to all the students before they were released for their summer vacation. There was also a problem found in manufacturing where Spanish language laptops were booting up in English. These two fixes, along with support for WPA were combined into a patch release, Ship2-653, that should be available for manufacturing early next week and to the general public soon thereafter. People interested in testing this patch can download the signed version (See http://download.laptop.org/xo-1/os/official/653/). The first G1G1 recipients have started receiving laptops this week. That means the calls, emails, IRC questions, and new community members are beginning to show up all over. This week Adam Holt set up these two Support wiki pages: http://wiki.laptop.org/go/Support and http://wiki.laptop.org/go/Support_FAQ, which is a good launching point for FAQs, as well as community-supported email, portals, and IRC. He also set up [EMAIL PROTECTED] and has begun the task of answering many emails. 6. Documentation: We have a number of new pages on laptop.org geared towards helping introduce the laptop to new users (Please see http://laptop.org/start). These pages will evolve (and hopefully improve) over the next few weeks as we get a better sense of the types of questions people are asking from the field—we've deployed more laptops in the past few weeks than in the entirety of our beta programs, so we expect a lot of valuable feedback in the coming days. Your feedback on these pages would also be greatly appreciated: please send email to walter AT laptop.org. The plan is to make these getting started pages available for translation in Pootle over the next week or so. Note that the page devoted to describing the activities (http://laptop.org/en/laptop/start/activities.shtml) directs people to the individual activity pages in the wiki, e.g., wiki.laptop.org/go/Journal. Please help us tidy up those pages as
Re: Enable security in Update.1 builds
On Dec 15, 2007 10:38 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Dec 15, 2007 4:36 PM, Michael Stone [EMAIL PROTECTED] wrote: The Roadmap lists activity isolation as a release criterion for Update.1. Was there a public announcement that I missed explaining why activity isolation was ever turned off? Michael, I don't think it was turned off. We branched update.1 from ship.2, and ship.2 had security disabled. Yes, I meant to create an update.1 branch for pilgrim based on joyride's pilgrim, but instead update.1 builds started being made from the old ship.2 branch (the state of the 'old' update.1 right before it was renamed to ship.2). I've gone through the diffs from joyride to update.1 carefully now, and with the exception of trac #5510 (evince-olpc renaming), trac #5153 (olpc-network-capture needs to be moved to olpc-utils), trac #5511(uncertain whether library cleanup has been done upstream), and the list of Activities (walter has promised me an updated list), the diff looks sane. FWIW, I have a number of pending pilgrim changes for update.1/joyride still: trac #3881 might require generation of a 'USB upgrade' blob for devel_jffs; trac #5320 (sshd configuration tweak); trac #5371 (olpc.fth tweak). They'll land in both update.1 and joyride before code freeze. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. I think you would be well served by making it clearer to people what the goals are of UBIFS relative to existing systems, such as JFFS2, on the XO. This may motivate more people to both do the testing and it may help better focus the feedback. thanks. -walter -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Builds and release process
On Dec 15, 2007 11:52 AM, Michael Stone [EMAIL PROTECTED] wrote: Scott has written very detailed instructions on how to do this but his documentation is currently located on the internalwiki in pursuit of, in my view, security by obscurity. Since I am not maintaining these servers, I do not wish to contradict his choice by publishing the contents of the server configuration pages; however, you might chat with him about ways that he would feel comfortable making this information more broadly visible. Michael, you're grossly mischaracterizing -- and being unhelpful to boot. Michael wrote a very useful README.olpc in the pilgrim source tree which describes how to set up pilgrim. The only details on the internalwiki are machine-specific configuration which will not be useful to you. Patches to README.olpc are always welcome. The only thing you really need is the pointer to git: http://dev.laptop.org/git?p=users/cscott/pilgrim The 'master' branch is generally what you need; there are separate branches for (again) machine-specific configuration (the 'autobuild' branch covers integration of pilgrim with our joyride build system, which is constantly changing). Sometimes branch-specific changes creep into (say) the ship.2 build which aren't in master; I try to avoid that whenever possible. Contributions to pilgrim should be made against the master branch. All this said, I really think that running your own pilgrim instance will only slow down your development process unless you are (like marco and bernie) responsible for a large number of inter-related packages. In general, RPM installing your modified packages on top of the latest joyride build is the recommended development process -- it's a lot faster! --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LOLPC
... and in a similar vein: http://cfrey.us/~erikb/ODDPC/ On 12/15/07, C. Scott Ananian [EMAIL PROTECTED] wrote: On Dec 15, 2007 1:14 AM, Ivan Krstić [EMAIL PROTECTED] wrote: http://live.laptop.org/~krstic/lolpc.jpg It had to be done. One Laptop Per Cat! --scott -- ( http://cscott.net/ ) ___ 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
New joyride build 1430
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1430/ -WikiBrowse-8.xo +WikiBrowse-9.xo -iptables.i386 0:1.3.8-2.1.fc7 +iptables.i386 0:1.3.8-6.fc7 -iptables-ipv6.i386 0:1.3.8-2.1.fc7 +iptables-ipv6.i386 0:1.3.8-6.fc7 -libshout.i386 0:2.2.2-1.fc6 +libshout.i386 0:2.2.2-2.fc7 -pam.i386 0:0.99.7.1-5.1.fc7 +pam.i386 0:0.99.7.1-5.2.fc7 --- WikiBrowse-9 --- * Updated to work in /home/olpc/Activities, where downloads will go -- 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
New joyride build 1431
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1431/ -Journal-80.xo +Journal-81.xo -Web-79.xo +Web-80.xo --- Journal-81 --- * Allow use of gamekeys and home/end, #3960 (rwh) * Focus does not escape from listview, #3771 (rwh) * Change resume icon color, #4326 (rwh) * Use standard star icon, #4327 (rwh) --- Web-80 --- * Update the progress of downloads less often #5449 (tomeu) -- 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: [PATCH] Make the OLPC build not depend on mkinitrd
Thanks, comments are inline.
On Fri, 14 Dec 2007 08:46:03 +0100
Bernardo Innocenti [EMAIL PROTECTED] wrote:
---
SPECS/olpc-2.6.spec |8 +++-
buildd.sh |2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/SPECS/olpc-2.6.spec b/SPECS/olpc-2.6.spec
index c823a54..2ead835 100644
--- a/SPECS/olpc-2.6.spec
+++ b/SPECS/olpc-2.6.spec
@@ -15,6 +15,9 @@ Summary: The Linux kernel (the core of the Linux operating
system)
%define buildkdump 0
%define buildheaders 1
+# Disable debuginfo package because it makes the build fail
+%define _enable_debug_packages 0
+
# Versions of various parts
There's no need to attempt to maintain any sort of compatibility with
the fedora kernel spec file. Rather than unsetting variables and keeping
tons of crap in the .spec file, I'd just as soon rip out anything that's
related to _enable_debug_packages.
How does it make the build fail, though? I haven't see that...
# After branching, please hardcode these values as the
@@ -213,8 +216,11 @@ Summary: The Linux kernel (the core of the Linux
operating system)
#
# Packages that need to be installed before the kernel is, because the %post
# scripts use them.
+# On the OLPC, we use a fancy initrd that doesn't rely on mkinitrd
+# We drop mkinitrd because it also drags in lvm2 and other nasty dependencies
#
-%define kernel_prereq fileutils, module-init-tools, initscripts =
8.11.1-1, mkinitrd = 4.2.21-1
+%define kernel_prereq fileutils, module-init-tools, initscripts = 8.11.1-1
\
+ %{?!olpc:, mkinitrd = 4.2.21-1}
I just dropped the mkinitrd bit completely; no need for an OLPC test.
Name: kernel
Group: System Environment/Kernel
diff --git a/buildd.sh b/buildd.sh
index 24ba127..6e8de51 100755
--- a/buildd.sh
+++ b/buildd.sh
@@ -7,7 +7,7 @@ GITWEB=http://dev.laptop.org/git?p=olpc-2.6;
if [ x$BRANCH = x ]; then
BRANCH=master
fi
-BUILDDIR=/home/dilinger/public_html/builds-${BRANCH}
+BUILDDIR=$HOME/public_html/builds-${BRANCH}
BASE=$BUILDDIR/`date '+%s'`
SUBLEVEL=$(wget -O- ${GITWEB};a=blob_plain;hb=${BRANCH};f=Makefile
2/dev/null | sed -ne
's/^.*SUBLEVEL[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p')
Thanks, committed this separately.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] Make the OLPC build not depend on mkinitrd
Andres Salomon wrote: There's no need to attempt to maintain any sort of compatibility with the fedora kernel spec file. Rather than unsetting variables and keeping tons of crap in the .spec file, I'd just as soon rip out anything that's related to _enable_debug_packages. YES! Please! How does it make the build fail, though? I haven't see that... I got an error No build ID note found that I tracked inside /usr/lib/rpm/find-debuginfo.sh Now I realized it's probably a Fedora 8 specific problem... I just dropped the mkinitrd bit completely; no need for an OLPC test. -- \___/ |___| 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: Builds and release process
Marco Pesenti Gritti wrote: Care to put quick instructions on the wiki? This is something I wanted to do several times, but never felt to invest the time to learn how. Done: http://wiki.laptop.org/go/Building_custom_images As usual, my questionable English needs some fixing, and I couldn't find the documentation in the internal wiki that mstone was talking about. -- \___/ |___| 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: Update.1 builds
C. Scott Ananian wrote: Almost the final location. As documented in trac bug #5279, ultimately all builds will be transferred to download.laptop.org after passing an automated test. So pilgrim is the 'final location' until we get the automated test infrastructure running, then everything will move to its real final home on download.laptop.org. Is joyride also moving? Please, remember to update the links in the wiki, especially the template that prints the summary information in the main page: http://wiki.laptop.org/go/Template:Latest_Releases Where are the development builds? has been a FAQ on IRC for some time. -- \___/ |___| 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
New joyride build 1432
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1432/ -cpio.i386 0:2.6-28.fc7 -dmraid.i386 0:1.0.0.rc14-4.fc7 -findutils.i386 1:4.2.29-2 -gzip.i386 0:1.3.11-2.fc7 -kernel.i586 0:2.6.22-20071213.7.olpc.807beb7d0b8a49a +kernel.i586 0:2.6.22-20071215.21.olpc.6fce16b65e15831 -kpartx.i386 0:0.4.7-11.fc7 -less.i386 0:394-9.fc7 -libdhcp4client.i386 12:3.0.5-40.fc7 -libdhcp6client.i386 0:0.10-44.fc7 -libdhcp.i386 0:1.24-4.fc7 -lvm2.i386 0:2.02.24-1.fc7 -mkinitrd.i386 0:6.0.9-7.1 -nash.i386 0:6.0.9-7.1 -olpc-utils.i386 0:0.53-1.olpc2 +olpc-utils.i386 0:0.58-1.olpc2 -parted.i386 0:1.8.6-4.fc7 -tar.i386 2:1.15.1-28.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
