New release8.2 build 753

[Build Announcer v2]

http://pilgrim.laptop.org/~pilgrim/xo-1/streams/8.2/build753

Changes in build 753 from build: 751

Size delta: -50.33M

-ohm 0.1.1-6.14.20080707git.olpc3
+ohm 0.1.1-6.17.20080805git.olpc3
+olpc-netutils 0.4-1.olpc3
+ntp-ntpdate 4.2.4p4-7.olpc3
-libertas-usb8388-firmware 2:5.110.22.p14-1.fc9
+libertas-usb8388-firmware 2:5.110.22.p17-1.olpc2
-kernel 2.6.25-20080708.1.olpc.198241e96d5b267
+kernel 2.6.25-20080813.4.olpc.cc866cfe0c31220
-hulahop 0.4.1-3.olpc3
+hulahop 0.4.3-1.olpc3
+ds-backup-client 0.7-1.olpc3
-gdb 6.8-11.fc9
+gdb 6.8-17.fc9
-etoys 3.0.2050-1
+etoys 2.2.1793-1
+PolicyKit-olpc 1.2-1.fc9
-cerebro 2.9.2-1.olpc3
+cerebro 2.9.12-1.olpc3
-olpcrd 0.46-0
+olpcrd 0.47-0
-olpc-utils 0.78-1.olpc3
+olpc-utils 0.83-1.olpc3
-olpcsound 5.08.92-2.olpc3
+olpcsound 5.08.92-8.olpc3
-pyabiword 0.6.0.svn20071127-1
+pyabiword 0.6.1-4.olpc3
-pygame 1.7.1-17.fc9
+pygame 1.8.0-1.olpc3.2
+python-alsaaudio 0.3-1.fc9
-rainbow 0.7.14-1.fc9
+rainbow 0.7.19-1.fc9
-sugar-journal 94-2.200807015git814c37616b.fc9
+sugar-journal 97-2.fc9
-sugar-evince-python 2.20.1.1-2.olpc3
+sugar-evince-python 2.20.1.1-3.olpc3
+sugar-update-control 0.8-1
-totem-mozplugin 2.23.4-1.olpc3.3
+totem-mozplugin 2.23.4-1.olpc3.4
-xorg-x11-drv-geode 2.9.0-2.fc9
+xorg-x11-drv-geode 2.10.0-1.olpc3.1
-xorg-x11-utils 7.4-1.fc9
+xorg-x11-utils 7.4-2.olpc3
-yum 3.2.16-2.fc9
+yum 3.2.17-2.fc9
-acl 2.2.47-1.fc9
+acl 2.2.47-2.fc9
-boost 1.34.1-13.fc9
+boost 1.34.1-15.fc9
-bootfw q2d16-1.olpc2.unsigned
+bootfw q2e12-1.olpc2.unsigned
-coreutils 6.10-27.fc9
+coreutils 6.10-30.fc9
-cyrus-sasl-lib 2.1.22-13.fc9
+cyrus-sasl-lib 2.1.22-15.fc9
-dbus-python 0.82.4-2.fc9
+dbus-python 0.83.0-2.fc9
+dnsmasq 2.41-0.8.fc9
-elfutils-libelf 0.133-3.fc9
+elfutils-libelf 0.135-1.fc9
-glib2 2.16.4-1.fc9
+glib2 2.16.5-1.fc9
-gnome-python2-gnomevfs 2.22.1-2.fc9
+gnome-python2-gnomevfs 2.22.1-3.olpc3
-gnome-python2 2.22.1-2.fc9
+gnome-python2 2.22.1-3.olpc3
-gnome-vfs2 2.22.0-1.fc9
+gnome-vfs2 2.22.0-3.olpc3
-gstreamer-plugins-base 0.10.19-2.fc9
+gstreamer-plugins-base 0.10.19-3.olpc3
-gstreamer-plugins-good 0.10.8-7.fc9
+gstreamer-plugins-good 0.10.8-8.fc9
-hal-info 20080607-1.fc9
+hal-info 20080607-1.olpc3.1
-hal 0.5.11-2.fc9
+hal 0.5.11-2.olpc3.1
-hal-libs 0.5.11-2.fc9
+hal-libs 0.5.11-2.olpc3.1
-initscripts 8.76.2-1.olpc3.6
+initscripts 8.76.2-1.olpc3.7
-libX11 1.1.4-1.fc9
+libX11 1.1.4-2.olpc3
-libacl 2.2.47-1.fc9
+libacl 2.2.47-2.fc9
-libabiword 1:2.6.4-5.olpc3
+libabiword 1:2.6.4-6.olpc3
+libpcap 14:0.9.8-2.fc9
-libvolume_id 124-1.fc9.2
+libvolume_id 124-2.fc9
-libxslt 1.1.24-1.fc9
+libxslt 1.1.24-2.fc9
-ncurses 5.6-16.20080301.fc9
+ncurses 5.6-18.20080628.fc9
-ncurses-base 5.6-16.20080301.fc9
+ncurses-base 5.6-18.20080628.fc9
-ncurses-libs 5.6-16.20080301.fc9
+ncurses-libs 5.6-18.20080628.fc9
+olpc-contents 2.4-1
+olpc-update 2.16-1
-openldap 2.4.8-6.fc9
+openldap 2.4.10-1.fc9
+poppler 0.6.2-5.olpc3
-pygtk2 2.12.1-6.fc9
+pygtk2 2.12.1-7.olpc3
-pygtk2-libglade 2.12.1-6.fc9
+pygtk2-libglade 2.12.1-7.olpc3
-rsyslog 3.16.1-2.fc9
+rsyslog 3.18.1-1.fc9
-speex 1.2-0.7.beta3
+speex 1.2-0.10.rc1.fc9
-squeak-vm 3.10-3olpc5
+squeak-vm 3.10-3olpc7
-sugar 0.81.6-4.20080715git8137d5c37f.fc9
+sugar 0.82.0-1.fc9
-sugar-artwork 0.81.1-2.20080709gitc77b345c02.fc9
+sugar-artwork 0.82.0-1.fc9
-sugar-evince 2.20.1.1-2.olpc3
+sugar-evince 2.20.1.1-3.olpc3
-sugar-base 0.81.2-3.fc9
+sugar-base 0.82.1-1.fc9
-sugar-datastore 0.8.3-1.olpc3
+sugar-datastore 0.82.0-1.fc9
-sugar-presence-service 0.81.3-1.olpc3
+sugar-presence-service 0.82.2-1.fc9
-sugar-toolkit 0.81.6-3.20080715gitd17347cc19.fc9
+sugar-toolkit 0.82.1-1.fc9
+tcpdump 14:3.9.8-4.fc9
-totem 2.23.4-1.olpc3.3
+totem 2.23.4-1.olpc3.4
-totem-gstreamer 2.23.4-1.olpc3.3
+totem-gstreamer 2.23.4-1.olpc3.4
-totem-pl-parser 2.23.2-1.olpc3
+totem-pl-parser 2.23.2-2.olpc3
-udev 124-1.fc9.2
+udev 124-2.fc9
-xapian-bindings-python 1.0.6-1.fc9
+xapian-bindings-python 1.0.7-2.fc9
-xapian-core-libs 1.0.6-1.fc9
+xapian-core-libs 1.0.7-1.fc9
-xkeyboard-config 1.2-3.fc9
+xkeyboard-config 1.3-2.olpc3
-xorg-x11-server-Xorg 1.4.99.902-3.20080612.olpc3.1
+xorg-x11-server-Xorg 1.4.99.906-2.olpc3
-xorg-x11-server-common 1.4.99.902-3.20080612.olpc3.1
+xorg-x11-server-common 1.4.99.906-2.olpc3
-ntp 4.2.4p4-6.fc9
-olpc-hardware-manager 0.4.2-1.fc9
-PolicyKit-gnome 0.8-4.fc9
-PolicyKit-gnome-libs 0.8-4.fc9
-audiofile 1:0.2.6-8.fc9
-bluecurve-icon-theme 8.0.2-1.fc9
-cdparanoia-libs 10.0-2.fc9
-control-center-filesystem 1:2.22.2.1-1.fc9
-dmraid 1.0.0.rc14-8.fc9
-esound-libs 1:0.2.38-7.fc9
-evolution-data-server 2.22.3-2.fc9
-fedora-gnome-theme 8.0.0-2.fc9
-fedora-icon-theme 1.0.0-1.fc8
-fedora-logos 9.0.0-2.fc9
-gail 1.22.3-1.fc9
-gnome-icon-theme 2.22.0-6.fc9
-gnome-keyring 2.22.3-1.fc9
-gnome-python2-bonobo 2.22.1-2.fc9
-gnome-mount 0.8-1.fc9
-gnome-themes 2.22.0-1.fc9
-gtk-nodoka-engine 0.7.0-1.fc9
-hunspell-en 0.20080207-1.fc9
-isomd5sum 1:1.0.4-1
-kpartx 0.4.7-16.fc9
-libart_lgpl 2.3.20-1.fc9
-libbonobo 2.22.0-2.fc9
-libbonoboui 2.22.0-2.fc9
-libdhcp 1.99.8-1.fc9
-li

Re: #8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system

[Bastien]

"Martin Langhoff" <[EMAIL PROTECTED]> writes:

>>> But my point was that, at the moment, you can choose to "Erase" an item, and
>>> it's gone forever. I expect that many kids will do this, and will at some 
>>> point
>>> regret erasing some item.
>>
>> Yes.  This is a request that has been made here in Haïti.
>
> AFAIK, the plan is to *discourage* deletion until the disk is getting
> full. When you are getting to disk-full, "trashcan" doesn't help.

Yes it does: it contains entries that the system can safely delete
without forcing the user to go thru the entries and sort them out on 
the fly.

People now want deletion because the Journal is not optimal.  They want
deletion to sort out entries in the Joural and get rid of unfinished or
useless entries.  With too many entries, the (current 703/708) Journal
becomes unusable.

They will eventually forget a bit about the trashbin when the Journal
will get better.  But even with a nicer Journal, the trashbin might
still serve the purpose described above.

> When you are running out off disk space, we have two cases:
>
>  - ds-backup has been doing its job, there's a copy of the files in
> the XS, so the journal has old-and-backed-up files that it can decide
> to rm

I'm afraid XS servers won't be of use in *many* schools.

>  - no old-and-backed-up files we can safely remove? Prompt the user

I'm curious whether someone did this job of being prompted.  
How long does it take?  If you can't remember what a file contains,
checking if it's safe to delete it by trying to reopen it might be
tiring.  

The whole idea of a trashbin has its limitation, but so does our brain! 

-- 
Bastien
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system

[Martin Langhoff]

On Wed, Aug 20, 2008 at 4:19 PM, Bastien <[EMAIL PROTECTED]> wrote:
> "Eduardo Heleno" <[EMAIL PROTECTED]> writes:
>
>> But my point was that, at the moment, you can choose to "Erase" an item, and
>> it's gone forever. I expect that many kids will do this, and will at some 
>> point
>> regret erasing some item.
>
> Yes.  This is a request that has been made here in Haïti.

AFAIK, the plan is to *discourage* deletion until the disk is getting
full. When you are getting to disk-full, "trashcan" doesn't help.

When you are running out off disk space, we have two cases:

 - ds-backup has been doing its job, there's a copy of the files in
the XS, so the journal has old-and-backed-up files that it can decide
to rm

 - no old-and-backed-up files we can safely remove? Prompt the user

cheers,



m
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system

[Bastien]

"Eduardo Heleno" <[EMAIL PROTECTED]> writes:

> But my point was that, at the moment, you can choose to "Erase" an item, and
> it's gone forever. I expect that many kids will do this, and will at some 
> point
> regret erasing some item.

Yes.  This is a request that has been made here in Haïti.

I'm not convinced myself, because I think the design of the (next)
Journal is neat, and the concept of a trashbin too MS-ish/clumsy. 

The only thing I find it useful for: send visual affordance to the 
user so that he *wants* to trash things (in a safe way) rather than
obeying the system when she's forced to delete stuff on a full disk.

-- 
Bastien
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system

[Eduardo Heleno]

2008/8/19 Zarro Boogs per Child <[EMAIL PROTECTED]>

> #8041: Sugar lacks a "Trash/Recycle bin" system
>
> +---
>   Reporter:  HoboPrimate   |   Owner:  Eben
>   Type:  enhancement   |  Status:  new
>   Priority:  high  |   Milestone:  9.1.0
>  Component:  interface-design  | Version:  Development build as of this
> date
>  Resolution:|Keywords:  9.1.0:?
> Next_action:  design|Verified:  0
>  Blockedby:|Blocking:
>
> +---
> Changes (by Eben):
>
>  * next_action:  never set => design
>  * cc: christianmarc, tomeu, martin.langhoff (added)
>  * priority:  normal => high
>  * version:  not specified => Development build as of this date
>  * milestone:  => 9.1.0
>  * keywords:  => 9.1.0:?
>
>
> Comment:
>
>  The Journal is, by design, meant to make a trash system completely
>  unnecessary, on account of an incremental backup mechanism that allows
>  kids to peruse record of (preview, title, description etc.) things they've
>  made and since deleted (much like looking in the trash), as well as
>  restore individual files from backup if they want to recover them again
>  (much like removing something from the trash).  There will, of course,
>  also be a way to permanently erase entries which they don't want any
>  record of anymore (much like emptying the trash).
>
>  Obviously, at some point, there won't be enough backup room either, and
>  things will have to go permanently, but this can be handled in much the
>  same way that the initial deletion process happens, which, as is described
>  in many other places, should guide the user through their documents,
>  suggesting a number of entries for deletion based on some heuristics
>  (including backup-present, file size, favorite status, recency of use,
>  frequency of use, etc.).
>
> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system


But my point was that, at the moment, you can choose to "Erase" an item, and
it's gone forever. I expect that many kids will do this, and will at some
point regret erasing some item.
I understand the idea of the backup system. I still propose for the
existence of a ~/.Trash directory, either on the XO, and/or on the users
/home directory at the backup server, used explicitly to store "erased"
entries, with strict limits on the size and age of items stored there.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!

[Eduardo Heleno]

2008/8/9 Christoph Derndorfer <[EMAIL PROTECTED]>

> On Thu, Aug 7, 2008 at 8:45 PM, Michael Stone <[EMAIL PROTECTED]> wrote:
> [snip]
>


> This isn't really a bug but rather a general observation so I'm not quite
> sure where to put it...
>
> When you're in the software-update panel of the control-panel then there
> are "cancel" and "ok" buttons in the upper right corner. However the "ok"
> button seems redundant as they both do exactly the same thing: close the
> panel and take you back to the main configuration screen. At least that's
> the case when the software is up-to-date. IIRC you also need to press a
> button inside the panel for updating when there's new software available
> which would again make the ok-button redundant.
>

I spotted this as well. Some other wording is necessary in here, perhaps an
"Accept" and "Cancel" buttons appear when changes are made, otherwise a
simple "Close" button appears.

Edu

>
> Cheers,
> Christoph
>
> --
> Christoph Derndorfer
> co-editor, olpcnews
> url: www.olpcnews.com
> e-mail: [EMAIL PROTECTED]
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New Test firmware

[Mitch Bradley]

Richard Smith wrote:

> I have a new test firmware up for all you brave firmware testers.  
> Last time I didn't give it enough soak time before rolling a q2e13 and 
> had to brown bag it.  So I'd appreciate testing across a bunch of 
> different builds.
>
> http://dev.laptop.org/~rsmith/q20158.rom

Andres found a problem with the above firmware, such that it won't boot 
the OS in unsecure mode with some versions of olpc.fth .

The problem is in the OFW bits (my bailiwick) instead of in Richard's EC 
bits.

I have build a new test version that includes the EC bits from Richard's 
test version above, along with a fix for the boot problem:

http://dev.laptop.org/~wmb/q2e13d.rom

Please test with q2e13d.rom instead of q20158.rom ; otherwise you are 
likely to experience problems.

Richard - svn head has the OFW fix.  My tests of your new EC bits have 
succeeded.  I have an installation where the touchpad fails with e13 and 
works with e13d .

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New joyride build 2311

[Build Announcer v2]

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2311

Changes in build 2311 from build: 2301

Size delta: 0.14M

-cerebro 2.9.11-1.olpc3
+cerebro 2.9.12-1.olpc3
-ds-backup-client 0.6-1.olpc3
+ds-backup-client 0.7-1.olpc3
-olpc-licenses 1-1
+olpc-licenses 2-1.olpc3

--- Changes for cerebro 2.9.12-1.olpc3 from 2.9.11-1.olpc3 ---
  + 2.9.12: Disabled UDP-based reports, #7942, #7961

--- Changes for ds-backup-client 0.7-1.olpc3 from 0.6-1.olpc3 ---
  + Scripts renamed for consistency
  + Cronjobs fixed to invoke the right scripts

--- Changes for olpc-licenses 2-1.olpc3 from 1-1 ---
  + Add spanish license translations

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

joyride version announcements

[Polychronis Ypodimatopoulos]

Why are new versions of Joyride not announced?

Pol
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Breaks yum also? (Was: Missing critical dependency, Koji)

[Gary C Martin]

On 18 Aug 2008, at 00:54, Martin Langhoff wrote:

> On Sat, Aug 16, 2008 at 3:31 AM, Gary C Martin  
> <[EMAIL PROTECTED]> wrote:
>> Just a quick double check – I take it that all yum attempted installs
>> will also be failing at the moment? Having re-flashed my XO last  
>> night
>> I was trying to pull in some additional system monitoring tools for
>> tests. Yom gives the error:
>
> I'm not sure about the Koji repo, but the release version scheme on
> the XO is breaking yum when it comes to vanilla Fedora packages,
> whiich is a shame.
>
> Workaround - with the example of installing lsof and gdb from the
> vanilla fedora repo:
>
> - replace $releasever with 9 in /etc/yum.repos.d/fedora.repo
> - run yum --disablerepo=olpc_devel --enablerepo=fedora install lsof  
> gdb
>
> Disabling olpc_devel only makes sense als long as the koji repo is  
> down.
>
> Time to split "fedorareleasever" from "olpcreleasever"? They are 2
> different beasts...

Thanks for the tip. I decided to lay low and get on with other tasks,  
but for others out there the infrastructure seems to be back up and  
running again (having just been able to successfully yum install git  
on my XO).

--Gary
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Localization] [Announce] New strings in Glucose 0.82

[Korakurider]

On Wed, Aug 20, 2008 at 6:43 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> Hello translators,
> It looks like we have got some new strings (no string freeze break
> though - apparently my POT updater broke for a few projects). Affected
> modules include sugar and journal (project glucose 0.82).
 Actually, both 0.82 branch (project glucose 0.82) and trunk
(project glucose) have been affected.

> It would be awesome if you can update your translations to cover the
> new strings.
  All of milestones for sugar 0.82 were over and 0.82 branched.
How and when fixed translations will be pulled to build?  Will we have
another build for sugar and journal for 8.2, or will we have to depend
on langpack for now and wait for 8.2.1?

/Korakurider

> Apologies for this, and I would try to make sure that this won't
> happen again in the future.
> Thanks,
> Sayamindu
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
> ___
> Localization mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/localization
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: reverting to ancient gstreamer, good time to implement change control?

[C. Scott Ananian]

On Tue, Aug 19, 2008 at 2:28 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
> We don't have a maintainer for the 8.2 build branch at the moment, so
> it's not trivial to do this.  I think Michael is planning on continuing
> to just use Joyride as the stream that will produce 8.2, until we get
> a new (or acting) build master who has time to maintain two trees.

No, I've revived the 8.2 build branch.  I haven't forked a stable bit
of koji yet (I could use some help); once we do that it should be
straightforward to pin the older gstreamer versions on our stable
branch.

I also support the "revert gstreamer for 8.2" plan.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Preparations for forking 8.2.

[C. Scott Ananian]

I've revived and turned the crank on the 8.2 branch in preparations
for forking a stable stream from joyride.  The build announcers will
probably shortly announce build 753, which should be more-or-less
identical to the latest joyride.  You can try it out with:
  # olpc-update 8.2-753

Although I will refresh again from joyride for a bit longer -- until
Michael tells me to stop -- consider this your first warning that
frozen times are approaching.  If you notice some way that build 753
diverges from joyride, or realize that we've been pulling, say, the
wrong etoys base image -- speak up now.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ejabberd XS package questions

[Martin Langhoff]

On Tue, Aug 19, 2008 at 11:56 PM, Guillaume Desmottes
<[EMAIL PROTECTED]> wrote:
> I'm working on the ejabberd package for the XS. We'd like to provide an
> updated package based on ejabberd 2.0.1 which "just work" once is
> installed. The goal is of course to simplify as much as possible the
> deployment of ejabberd servers for schools and community users.

Good goals, though there's a tricky aspect in that we don't know the
domain name at install time, and AFAIK ejabberd doesn't like the
domain being changed after the DB has been setup.

Following that, my intention is to automate the setup steps that need
to take place once the fqdn has been set.

> My current package is hosted in this git repo:
> http://git.collabora.co.uk/?p=user/cassidy/ejabberd-rpm;a=shortlog;h=refs/heads/XS

Great.

> Here is few points I'd like to discuss:
>
> - Where are hosted XS packages source? I guess my ejabberd package
> should belong here.

xs-dev. Have you got an acct there? If not, send me and Henry Hardy
your public keys and we'll set things up.

> - /etc/ejabberd/ejabberd.pem is not installed by current XS package but
> xs-config provide it. Recently, the Fedora's devel package was updated
> to generate this file at the package installation (#5834). I integrated
> this change in my package so we'll probably have to drop ejabberd.pem
> from xs-config.

Yes. I've seen your .pem generation, and I think it's a good idea. As
soon as we clear your new pkg for installation I'll remove the .pem
file from xs-config.

> - Same question about ejabberd.cfg which is currently overridden by
> xs-config. The XS package should directly provide the right conf file I
> guess.

Your package should provide a default cfg. xs-config will have scripts
that will override it (I'm changing how that works at the moment to
make it saner) with a config file that is specific to the XS.

A couple of questions WRT your package:

 - How is it different from the one in F9? New/added files? Patched files?

 - Can we make it so that it is _only_ additional files? If so, then
we could make it into a package that depends on F9's ejabberd.

cheers,




m
-- 
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New Test firmware.

[Richard A. Smith]

I have a new test firmware up for all you brave firmware testers.  Last 
time I didn't give it enough soak time before rolling a q2e13 and had to 
brown bag it.  So I'd appreciate testing across a bunch of different builds.

http://dev.laptop.org/~rsmith/q20158.rom

Thanks.

-- 
Richard Smith  <[EMAIL PROTECTED]>
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: reverting to ancient gstreamer, good time to implement change control?

[Erik Garrison]

On Tue, Aug 19, 2008 at 02:23:27PM -0400, Daniel Drake wrote:
> Hi,
> 
> I've spent too many hours on Record and there are still outstanding
> blockers. I'm pretty stumped on one of them:
> http://dev.laptop.org/ticket/7452
> http://marc.info/?l=gstreamer-devel&m=121848539729018&w=2
> 
> And haven't even started looking at the others:
> http://dev.laptop.org/ticket/7887
> http://dev.laptop.org/ticket/7609
> 
> However, I do have a fix! It involves reverting to the following
> versions:
> gstreamer-0.10.12-1
> gstreamer-plugins-base-0.10.12-4
> gstreamer-plugins-good-0.10.5-7
> gstreamer-python-0.10.7-2
> Record-54
> 
> This is what we shipped in update1. Everything works rather well
> (despite being told by gstreamer developers that Record's pipeline
> should never have worked!)
> 
> After reverting, I will attempt to get gstreamer developers involved in
> fixing those bugs. I wonder if the fact that we are shipping such an old
> version would act as motivation for them to help fix it. I will try and
> get them hardware through the developer program.
> 
> I can take care of everything on the Fedora/rebuilding side. RPMs here:
> http://dev.laptop.org/~dsd/20080819/
> 
> How do people feel about the above?
> 

I think this is a fine solution for the moment.  Let it rest, and save
your time for more salvagable ventures.  We can move forward when we
have more time to spend on the issue and/or gstreamer understands itself
better.  You have made it a long way towards the completion of a
much-needed rewrite of Record but there isn't time to complete it prior
to the release.

Erik
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: reverting to ancient gstreamer, good time to implement change control?

[Chris Ball]

Hi,

   > How do people feel about the above?

Excellent, we should do that and retarget the more involved work for the
next release.

   > Assuming we go ahead, I feel this would be a good time to enter
   > change control. We would only implement the gstreamer reversion in
   > the 8.2 branch, and leave joyride with the buggy but current
   > gstreamer. Any thoughts on that?

We don't have a maintainer for the 8.2 build branch at the moment, so
it's not trivial to do this.  I think Michael is planning on continuing
to just use Joyride as the stream that will produce 8.2, until we get
a new (or acting) build master who has time to maintain two trees.

Thanks,

- Chris.
-- 
Chris Ball   <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

reverting to ancient gstreamer, good time to implement change control?

[Daniel Drake]

Hi,

I've spent too many hours on Record and there are still outstanding
blockers. I'm pretty stumped on one of them:
http://dev.laptop.org/ticket/7452
http://marc.info/?l=gstreamer-devel&m=121848539729018&w=2

And haven't even started looking at the others:
http://dev.laptop.org/ticket/7887
http://dev.laptop.org/ticket/7609

However, I do have a fix! It involves reverting to the following
versions:
gstreamer-0.10.12-1
gstreamer-plugins-base-0.10.12-4
gstreamer-plugins-good-0.10.5-7
gstreamer-python-0.10.7-2
Record-54

This is what we shipped in update1. Everything works rather well
(despite being told by gstreamer developers that Record's pipeline
should never have worked!)

After reverting, I will attempt to get gstreamer developers involved in
fixing those bugs. I wonder if the fact that we are shipping such an old
version would act as motivation for them to help fix it. I will try and
get them hardware through the developer program.

I can take care of everything on the Fedora/rebuilding side. RPMs here:
http://dev.laptop.org/~dsd/20080819/

How do people feel about the above?

Assuming we go ahead, I feel this would be a good time to enter change
control. We would only implement the gstreamer reversion in the 8.2
branch, and leave joyride with the buggy but current gstreamer. Any
thoughts on that?

Thanks,
Daniel


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

schedule suggestion

[Ricardo Carrano]

Hello all!

For 9.1 on, I suggest the release schedule to happen before people
begin to take their breaks.
December and August are probably hard months to get a big team push,
due to vacations.
Maybe it would be the case to bring this to June and November.

Just a thought.

Cheers!
Ricardo
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Missing critical dependency, Koji

[C. Scott Ananian]

On Fri, Aug 15, 2008 at 12:37 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 15, 2008 at 02:13:28PM +1000, James Cameron wrote:
>>We don't have a duplicate of Koji we can use?  How wrong is that!
>
> We talked about it but Dennis argued passionately that
>
>   a) creating our own koji instance would be additional infrastructure
>   that we can ill-afford to maintain and
>
>   b) that creating our own koji instance would encourage sloth and
>   laziness on the part of developers who were already reluctant to learn
>   to do things the proper (Fedora) way.
>
> Anyway, in the meantime, we have raw rpmbuild, mock (which needs to be
> configured not to use Fedora's koji, but this is not so hard), our own
> buildroot (probably hidden away somewhere on weka.laptop.org), and the
> joyride dropbox system. In conclusion, we'll live.

Hmm, I don't think we're really as good as that.  Many of our core
processes are tied into koji now.  All our makefiles need to be
rewritten to use mocks '--offline' option, and that doesn't always
work.  The buildroot configuration we are using is tied to koji's
static olpc3 repo.  Work around here has certainly ground to a halt.

We should certainly transition to processes that are not as tightly
coupled; at a minimum, we should maintain a mirror of the koji build
root.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Missing critical dependency, Koji

[C. Scott Ananian]

On Sun, Aug 17, 2008 at 8:27 PM, John Gilmore <[EMAIL PROTECTED]> wrote:
>> Anyway, in the meantime, we have raw rpmbuild, mock (which needs to be
>> configured not to use Fedora's koji, but this is not so hard), our own
>> buildroot (probably hidden away somewhere on weka.laptop.org), and the
>> joyride dropbox system. In conclusion, we'll live.
>
> I got an impression that all we were using koji for was to pull in
> binaries of F9 packages that olpc had never modified.  If that's true,

That's not quite true.  We also have an 'olpc3' branch of the rpm
sources in koji, and many packages use it to manage their builds.  In
fact, perhaps all packages live in koji except those packages
maintained by the etoys folks and me.

That's not "upstream" sources, that's the "packaging" sources: the rpm
spec files and patches and such.  Still, that's a significant amount
of work (as we discovered the hard way with the F9 rebase.)

> we can quickly set up our own mirror by starting with an F9 binary
> install DVD (readily available from mirrors or BitTorrent; I'm serving it
> up myself on BT), and updating it with any packages revised in
> Fedora Updates (also available on mirrors).

Again, that doesn't include all the packages we've locally modified;
nor does it include F9 "updates", which we've been pulling in.

> until it is.  I also recommend getting enough control of our own build
> system that we have *saved* enough source and binary RPM's to fully
> reproduce every release we subsequently build.  (The ability to
> rebuild an identical release is key to retaining the ability to make a
> slightly evolved release that contains only well defined changes.)

We do this for stable builds; the problem was/is that we hadn't forked
a stable build from joyride yet as of the time of the koji outage.

> Currently I'm sure we don't have src.rpm's for everything we have in
> binary.  (If anybody knows where the olpc-licenses src.rpm is, we're
> actively looking for it so we can fix it!)

http://mock.laptop.org/gitweb/gitweb.cgi?p=repos;a=tree;f=SRPMS;h=ec5cc9c74ca05b64d66813bf08b8bb87dcbb540f;hb=HEAD

> BTW, the Fedora sysadmins are being mysterious about the "issues we
> discovered earlier this week" that caused them to take down Koji:
[...]
> It smells to me like an attack, perhaps designed to corrupt the master
> packages that large numbers of people are downloading in binary and
> installing without question :-(.

Putting my less-paranoid hat on, I'd say: almost certainly an attack,
but I'm guessing they are veeery carefully comparing all their
repositories and systems against backup before saying whether (or not)
their master packages or source repos were compromised.  The caution
seems justified: they should make they understand exactly what was
changed and why before making any statements about what was/was not
attacked/vulnerable/compromised.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!

[Eben Eliason]

On Tue, Aug 19, 2008 at 5:42 AM, Eduardo Heleno <[EMAIL PROTECTED]> wrote:
> 2008/8/9 Christoph Derndorfer <[EMAIL PROTECTED]>
>>
>> On Thu, Aug 7, 2008 at 8:45 PM, Michael Stone <[EMAIL PROTECTED]> wrote:
>> [snip]
>
>
>>
>> This isn't really a bug but rather a general observation so I'm not quite
>> sure where to put it...
>>
>> When you're in the software-update panel of the control-panel then there
>> are "cancel" and "ok" buttons in the upper right corner. However the "ok"
>> button seems redundant as they both do exactly the same thing: close the
>> panel and take you back to the main configuration screen. At least that's
>> the case when the software is up-to-date. IIRC you also need to press a
>> button inside the panel for updating when there's new software available
>> which would again make the ok-button redundant.
>
> I spotted this as well. Some other wording is necessary in here, perhaps an
> "Accept" and "Cancel" buttons appear when changes are made, otherwise a
> simple "Close" button appears.

Actually, the intent is to make the Accept button insensitive until
changes are made, so that the options are "leave without making
changes" (regardless of whether or not I changed anything), and "leave
and accept changes made" (only available when there are changes).
There is a patch for this, but it hasn't yet been accepted.
(http://dev.laptop.org/ticket/7643)

- Eben

> Edu
>>
>> Cheers,
>> Christoph
>>
>> --
>> Christoph Derndorfer
>> co-editor, olpcnews
>> url: www.olpcnews.com
>> e-mail: [EMAIL PROTECTED]
>>
>> ___
>> Sugar mailing list
>> [EMAIL PROTECTED]
>> http://lists.laptop.org/listinfo/sugar
>>
>
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

ejabberd XS package questions

[Guillaume Desmottes]

Hi,

I'm working on the ejabberd package for the XS. We'd like to provide an
updated package based on ejabberd 2.0.1 which "just work" once is
installed. The goal is of course to simplify as much as possible the
deployment of ejabberd servers for schools and community users.

My current package is hosted in this git repo:
http://git.collabora.co.uk/?p=user/cassidy/ejabberd-rpm;a=shortlog;h=refs/heads/XS

Here is few points I'd like to discuss:

- Where are hosted XS packages source? I guess my ejabberd package
should belong here.

- /etc/ejabberd/ejabberd.pem is not installed by current XS package but
xs-config provide it. Recently, the Fedora's devel package was updated
to generate this file at the package installation (#5834). I integrated
this change in my package so we'll probably have to drop ejabberd.pem
from xs-config.

- Same question about ejabberd.cfg which is currently overridden by
xs-config. The XS package should directly provide the right conf file I
guess.


Thanks


G.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel