Re: OLPC vs Fedora packages
by Peter Robinson
>> sugar-evince - Probably need to get evince split into evince-libs and
>> evince so that sugar-evince can build against evince-libs. Not sure if
>> there's plans to get sugar-evince upstreamed for easy maintenance
>
> Yesterday was working in upstreaming our patches. I really really hope
> that we can ship a working Read activity in the next releases of the
> major distros. You can track the effort here:
> http://sugarlabs.org/go/Evince
Is there an upstream bug report?
Peter
15 years, 4 months
Re: OLPC vs Fedora packages
by Peter Robinson
On Thu, Jan 15, 2009 at 10:14 AM, Tomeu Vizoso <tomeu(a)sugarlabs.org> wrote:
> On Thu, Jan 15, 2009 at 05:15, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>
>> - xulrunner and the OLPC patches (currently using mainline Fedora
>> package) - Mario & Simon
>
> I have seen that in trunk the native theme can be enabled and disabled
> in runtime, so that would be one patch less. I'm not 100% sure it got
> into 1.9.1, though.
Do you know if there's a upstream bugzilla.mozilla.org bug number?
Peter
15 years, 4 months
OLPC vs Fedora packages
by Peter Robinson
Just thought I'd post my understanding of where the packages are at
based on the list that was created at FUDCon
For reference see https://fedoraproject.org/wiki/OLPC/Packages_for_F11
Also there's the OLPCDelta tracking bug in RHBZ 462625 for quick
tracking of the ones I'm aware of.
KOJI packages
GConf-dbus - Should be able to untag. I think its also used to reduce
the deps on bonobo etc.
SDL_mixer - see RHBZ 471623 - Need someone to update if my thoughts are correct.
abiword - mostly forked to reduce dependencies on things like
printing. Probably will be unnecessary with the next major release as
most of the old deps on libgnome libgnomeprint etc should disappear
hippo-canvas - From my testing bigboard and mugshot compile OK but I
can't really test so it should be mergeable.
hulahop - OLPC-4 branch merged (and removed) just waiting for the push
to mainline. Push to testing just happened today. So can essentially
be removed from this list.
initscripts - I seem to remember the main reason was due to rainbow
using process number 1 and hence initscripts running as process number
2. JKatz is the one in the know here.
olpc-utils - due to olpcupdate not being in Fedora and its dependant on it.
sugar-evince - Probably need to get evince split into evince-libs and
evince so that sugar-evince can build against evince-libs. Not sure if
there's plans to get sugar-evince upstreamed for easy maintenance
telepathy* - no idea but its documented well by others :-)
totem-* - dependency reduction - I think these can probably mostly go
away with the plans to introduce the ability for multiple desktops to
run (sugar and something else) as e-d-s will probably be there anyway
upstart - I believe its the same as for initscripts (rainbow). This I
think is another one for JKatz. I also think there was discussion on
fedora-olpc back in Sept/Oct timeframe.
JOYRIDE packages
libertas-usb8388-firmware - is in Fedora-10 and rawhide already. I
thought I'd unlinked the non mainline version as we were shipping the
same package in F-10 as we are for 9.1.0 and rawhide has the latest
(or near latest) version.
I'll also link the RHBZ bugs if there is one near each of the
mentioned packages in the wiki.
Cheers,
Peter
15 years, 4 months
Re: packaging for native OLPC platform
by Mikus Grinbergs
> Can you do a rpm -qa | grep glibc and see if the glibc reports the
> i686 version? I've seen this before with some of the AMD geode
> processors where the build process uses the i686 package as it can run
> fine on this particular AMD processor but in actual fact its an i586
> processor so yum/rpm think there should be the i386 version and hence
> don't see that glibc.i686 needs upgrading but glibc-common being i386
> does but conflicts.
Thank you. This is indeed what seems to be happening.
[I guess this is one situation where a "smart" tool reaches a
more-difficult-to-use conclusion than a "dumb" human.]
> You can force the upgrade by downloading the rpms
> and using "rpm -Uvh --ignorearch glibc-package-names.rpm"
Tried it for the fun of it but there was something wrong with the
downloaded files. In any case, OLPC has released a newer-yet build
which I've now installed, instead of fooling with upgrading the old
build.
Thank you for your assistance and explanation, mikus
15 years, 4 months
Greg Smith Over and Out
by Greg Smith
Hi All,
My time on this project is over for now! I was laid off yesterday and
tomorrow is my last day at OLPC.
So many things to follow up on, its hard to know where to begin handing
off. I can say that XO Camp is on for next week as planned. SJ is now
coordinating it.
Aside from that, contact Ed McNierney <ed at laptop dot org> for any
development questions or anything else on my plate.
I'm sorry to drop the ball, but I need to find a new job ASAP. Perhaps I
can participate again in the future but I'm unsubscribing from all lists
as of tomorrow.
If I can pass along some history or other work, don't hesitate to
contact me.
My new e-mail address: gregsmithpm(a)gmail.com.
To come to OLPC, I left a safe and lucrative job making some of the most
advanced computers in the world. I took a big risk to work on what I
think is important and I gave it everything I could.
I have no regrets. I'm proud of what I accomplished and honored to have
been a member of this great community.
Its time to go back and take care of my own family again. Let me know if
anyone has leads on Product Manager openings in Massachusetts or
tele-commuting. My technical specialties have been high-end routers and
networking, distributed server architectures, image and video
processing, and online marketing including data analysis. Now I'll add
open source development, social networking/Web 2.0, educational
software, low cost computing and wireless networking to that list ;-)
As a product manager, I write the business case and technical
requirements and manage all aspects of the project to get a quality
product built and shipped on time. Give me n engineers to work with and
I'll give you n Million $s in revenue in the first year and double that
every 6 months after.
That's my new pitch :-) Send me an e-mail with any leads or for a copy
of my resume.
Good luck! Please keep at it if you can. There are hundreds of thousands
of kids using the XO now. Regardless of organizational priorities, they
deserve the very best software available.
Thanks,
Greg S
15 years, 4 months
Re: Fedora Desktop on XO
by John Gilmore
> I'm very interested on this, as it would give us also for free a FUSE
> interface. Why I haven't pursued it yet is because the API for
> developing new gio backends is still private and our new backend would
> then need to live inside the gvfs gnome module or as a patch in every
> distro. Aside from having to periodically adapt to any API changes.
>
> See http://mail.gnome.org/archives/gvfs-list/2008-May/msg00004.html
>
> That said, such a backend would be very simple, for the journal in Sugar 0.84.
Hi Tomeu, I'd say write the simple backend and submit it upstream. Their
interface sounds very much like every other interface in a computer,
i.e. not quite done right in retrospect and always subject to change.
Their mailing list only got a dozen messsages that month -- it's not
evolving SO fast. Host the code in their gnome module and then it'll
evolve along with the module and also go into each distro.
My idea is that when an ordinary GUI program pops up an "Open File"
dialog, if an OLPC Journal exists for that user, it will be one of the
icons in the left column (like "Desktop" or "File System" or each
mounted removable storage device). If Journal is already the default,
or is selected, then the filename and type are pre-defaulted, though
the user can override them by typing.
Even on a sugarized OLPC, people are going to neet to touch files that
have real names in the real filesystem (e.g. Python source code,
config files, even new firmware downloads) as well as Journal entries,
so they'll need ways to pick things OTHER than the Journal, too.
This design would also let people try out the Journal concept, just by
"apt-get install olpc-journal" and starting it up. Then by picking
Journal in the file dialog or file browser, it will arrange the files
that they save or read, by date of access in one big glob, with tags
or whatever, rather than making them pick hierarchical names. This
would all happen modularly, without installing the Sugar GUI. (It
would only be interfaced to Sugar and Gnome, but maybe other desktops
would get the hint.)
This would also be a really cheap way to browse USB keys, etc. Open
two Gnome file browsers (one hierarchical in USB key; the other in
Journal) and drag things back and forth. The code's already there,
it just lacks this one interface.
John
15 years, 4 months
packaging for native OLPC platform
by Mikus Grinbergs
Whenever I install a new build on my XO, I apply certain
customizations. If the difference between the new build and the
previous one is small, I might instead 'update' the previous build
(which already has my customizations) with the proper individual
packages (rather than doing the whole install / customize deal).
The difference between the Joyride-2616 build and the Joyride-2617
build was two packages: glibc & glibc-common. Yet when I tried to
use 'yum' to fetch and apply these two packages to my Joyride-2616
system, 'yum' failed with the error "glibc-common <version being
replaced> is needed by glibc <version being replaced> (installed)."
Obviously, in this case 'yum' had failed to solve "dependency hell".
mikus
15 years, 4 months
Re: Fedora Desktop on XO
by Rahul Sundaram
Erik Garrison wrote:
> On Wed, Jan 07, 2009 at 07:47:36AM +0530, Rahul Sundaram wrote:
>> One thing, we try not to do, is deviate from upstream and apply many
>> patches like some of the other Xfce based spin-off's do which is a
>> general Fedora policy as well and not something specific to the Xfce
>> team.
>
> The patches I described (e.g. desktop icon creation) appear to have
> been backported from the development version of XFCE. Is backporting
> patches from the mainline XFCE development against policy?
There isn't a strict policy against anything, there is a set of
recommendations outlined at
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_ha...
Backporting is usually more accepted since the upstream path is clear
and we don't have carry them forever. If you have specific suggestions
(and pointers to those patches if any), then please report them in
bugzilla and the maintainers involved can consider them on a case by
case basis.
If you wish to discuss ideas, post to fedora-devel list or ping nirik
(Kevin Fenzi) in #fedora-devel. I am mether on irc and available on all
the usual channels as well.
Rahul
15 years, 4 months