Hi,
After seeing the community help significantly with F11-on-XO development, I'm wondering if we can do something similar for a future release. So, I've taken the first few steps in getting OLPC's technologies rebased on Fedora 14 and Linux v2.6.35.
The result has lots of problems, but I figure that publishing the work so far is the first step in getting things fixed.
Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
For now, please don't file bugs unless you include patches. And, to take 1 bite at a time out of this huge task, lets ignore all but the biggest sugar issues for now because there is plenty of OS work to be done first. (or alternatively lets take sugar issues directly to SL trac)
And the links: 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35 OS build is done from 'f14' branch of olpc-os-builder First released images are at http://build.laptop.org/F14/os1/ Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate TODO), please don't file tickets unless you include patches in these early days
Note: I haven't tested those exact images (since Chris @ OLPC built them), so boot-testing them can be the first task for someone. I have been working from the same codebases making local images successfully, so they will probably work (to the extent that things are working).
At this point this is all something put together by me in my spare time. It's not known if or when OLPC would start working on an official release from these efforts. But I figure that if we get things properly stabilized and all the work is done cleanly, we'll find one way or another to get this in the hands of deployments.
Daniel
Hey Daniel,
Yippee! I suspect the sugar starting issues is the same one we're seeing in SoaS for F-14. I'm very busy until Sunday but i hope to have at least some time to be able to look at that problem and help you out where possibly as no doubt both SoaS and the builds for the XO will share a lot of common problems.
With the kernel nearing a recent release is there any plans to get a chunk of the kernel patches upstream to ease on going maintenance?
As always ping me if there's anywhere specific I can be of assistance in upstream Fedora.
Peter
On Wed, Sep 1, 2010 at 6:22 AM, Daniel Drake dsd@laptop.org wrote:
Hi,
After seeing the community help significantly with F11-on-XO development, I'm wondering if we can do something similar for a future release. So, I've taken the first few steps in getting OLPC's technologies rebased on Fedora 14 and Linux v2.6.35.
The result has lots of problems, but I figure that publishing the work so far is the first step in getting things fixed.
Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
For now, please don't file bugs unless you include patches. And, to take 1 bite at a time out of this huge task, lets ignore all but the biggest sugar issues for now because there is plenty of OS work to be done first. (or alternatively lets take sugar issues directly to SL trac)
And the links: 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35 OS build is done from 'f14' branch of olpc-os-builder First released images are at http://build.laptop.org/F14/os1/ Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate TODO), please don't file tickets unless you include patches in these early days
Note: I haven't tested those exact images (since Chris @ OLPC built them), so boot-testing them can be the first task for someone. I have been working from the same codebases making local images successfully, so they will probably work (to the extent that things are working).
At this point this is all something put together by me in my spare time. It's not known if or when OLPC would start working on an official release from these efforts. But I figure that if we get things properly stabilized and all the work is done cleanly, we'll find one way or another to get this in the hands of deployments.
Daniel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
This is awesome news, kudos to Daniel.
On Wed, Sep 1, 2010 at 08:49, pbrobinson@gmail.com pbrobinson@gmail.com wrote:
Hey Daniel,
Yippee! I suspect the sugar starting issues is the same one we're seeing in SoaS for F-14.
Hmm, I had some trouble on mainstream F-14 booting both Sugar and GNOME (actually, even logging into the console was failing) but booting with enforce=0 fixed it until an update fixed it for good.
Is it something different?
At this point I'm booting into Sugar from gdm without problems.
Regards,
Tomeu
I'm very busy until Sunday but i hope to have at least some time to be able to look at that problem and help you out where possibly as no doubt both SoaS and the builds for the XO will share a lot of common problems.
With the kernel nearing a recent release is there any plans to get a chunk of the kernel patches upstream to ease on going maintenance?
As always ping me if there's anywhere specific I can be of assistance in upstream Fedora.
Peter
On Wed, Sep 1, 2010 at 6:22 AM, Daniel Drake dsd@laptop.org wrote:
Hi,
After seeing the community help significantly with F11-on-XO development, I'm wondering if we can do something similar for a future release. So, I've taken the first few steps in getting OLPC's technologies rebased on Fedora 14 and Linux v2.6.35.
The result has lots of problems, but I figure that publishing the work so far is the first step in getting things fixed.
Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
For now, please don't file bugs unless you include patches. And, to take 1 bite at a time out of this huge task, lets ignore all but the biggest sugar issues for now because there is plenty of OS work to be done first. (or alternatively lets take sugar issues directly to SL trac)
And the links: 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35 OS build is done from 'f14' branch of olpc-os-builder First released images are at http://build.laptop.org/F14/os1/ Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate TODO), please don't file tickets unless you include patches in these early days
Note: I haven't tested those exact images (since Chris @ OLPC built them), so boot-testing them can be the first task for someone. I have been working from the same codebases making local images successfully, so they will probably work (to the extent that things are working).
At this point this is all something put together by me in my spare time. It's not known if or when OLPC would start working on an official release from these efforts. But I figure that if we get things properly stabilized and all the work is done cleanly, we'll find one way or another to get this in the hands of deployments.
Daniel _______________________________________________ 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
On 1 September 2010 00:49, pbrobinson@gmail.com pbrobinson@gmail.com wrote:
With the kernel nearing a recent release is there any plans to get a chunk of the kernel patches upstream to ease on going maintenance?
I cleaned up the history a lot, which is the first big step in doing this. It's a task I'd be interested in doing, but I'm not sure what priority I'll give it.
Thanks, Daniel
El Tue, 31-08-2010 a las 23:22 -0600, Daniel Drake escribió:
Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
I recommend rebasing on the geode driver 2.11.9, which was just released by upstream. I've been testing it in Dextrose for about 3 weeks: it fixes all the known rendering bugs and has no regressions.
Hopefully it will also work well on newer X servers, but I have not had the opportunity to test yet. If you're ok with it, I could upgrade the xorg-x11-drv-geode package in Fedora 14.
I really admire the work you're doing and wish I could help more than this, but time to work on XO builds is up for me. From now on I'll have just enough time to finish spinning-off Dextrose 2 in the hands of deployments.
the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
I recommend rebasing on the geode driver 2.11.9, which was just released by upstream. I've been testing it in Dextrose for about 3 weeks: it fixes all the known rendering bugs and has no regressions.
The XO-1 os1 build already has xorg-x11-drv-geode-2.11.9-1.fc14.olpc1
--- On Wed, 9/1/10, Mikus Grinbergs mikus@bga.com wrote:
I recommend rebasing on the geode driver 2.11.9, which
was just released
by upstream. I've been testing it in Dextrose for
about 3 weeks: it
fixes all the known rendering bugs and has no
regressions.
The XO-1 os1 build already has xorg-x11-drv-geode-2.11.9-1.fc14.olpc1
This driver should be ported to F11/10.1.2 ASAP. Is day and night compared to 2.11.8 when I run it in puppy. The XO-1 is like a new machine. pls do _not_ wait for 10.1.3
On 1 September 2010 10:14, Yioryos Asprobounitis mavrothal@yahoo.com wrote:
This driver should be ported to F11/10.1.2 ASAP. Is day and night compared to 2.11.8 when I run it in puppy. The XO-1 is like a new machine. pls do _not_ wait for 10.1.3
That's impossible. 10.1.2 has been released.
Daniel
--- On Wed, 9/1/10, Daniel Drake dsd@laptop.org wrote:
From: Daniel Drake dsd@laptop.org Subject: Re: Initial F14 developers-only release for XO and XO-1.5 To: "Yioryos Asprobounitis" mavrothal@yahoo.com Cc: "Bernie Innocenti" bernie@codewiz.org, mikus@bga.com, "OLPC Devel" devel@lists.laptop.org, "fedora-olpc-list" fedora-olpc-list@redhat.com Date: Wednesday, September 1, 2010, 12:16 PM On 1 September 2010 10:14, Yioryos Asprobounitis mavrothal@yahoo.com wrote:
This driver should be ported to F11/10.1.2 ASAP. Is
day and night compared to 2.11.8 when I run it in puppy. The XO-1 is like a new machine.
pls do _not_ wait for 10.1.3
That's impossible. 10.1.2 has been released.
:-) I guess what I imply is an F11 rpm. But you answer brings up an interesting issue, an "olpc-critical-update" mechanism similar to "software update". Lets say a variant of yum with only one specific repo, or even just yum with only the olpc repo. A "yum-olpc" script
Daniel
On Wed, Sep 1, 2010 at 2:30 PM, Yioryos Asprobounitis mavrothal@yahoo.com wrote:
This driver should be ported to F11/10.1.2 ASAP. Is
day and night compared to 2.11.8 when I run it in puppy. The XO-1 is like a new machine.
pls do _not_ wait for 10.1.3
That's impossible. 10.1.2 has been released.
:-) I guess what I imply is an F11 rpm. But you answer brings up an interesting issue, an "olpc-critical-update" mechanism similar to "software update". Lets say a variant of yum with only one specific repo, or even just yum with only the olpc repo. A "yum-olpc" script
Yioryos,
can you spin a F11 RPM of 2.11.9? If it's much improved, and a good testing shows it has no regressions, it's a candidate for 10.1.3.
I will be pushing a nice list of fixups for 10.1.3 :-)
m
El Wed, 01-09-2010 a las 15:55 -0300, Martin Langhoff escribió:
can you spin a F11 RPM of 2.11.9? If it's much improved, and a good testing shows it has no regressions, it's a candidate for 10.1.3.
Enjoy:
rpm -Uvh http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/xorg-x11-dr...
El Thu, 02-09-2010 a las 01:07 +0200, Bernie Innocenti escribió:
rpm -Uvh http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/xorg-x11-dr...
The .fc14 is my mistake, this package is actually built for Fedora 11.
On Thu, Sep 2, 2010 at 4:26 PM, Bernie Innocenti bernie@codewiz.org wrote:
El Thu, 02-09-2010 a las 01:07 +0200, Bernie Innocenti escribió:
rpm -Uvh http://download.sugarlabs.org/dextrose/testing/dxo2/rpms/i386/os/xorg-x11-dr...
The .fc14 is my mistake, this package is actually built for Fedora 11.
Ah! I was wondering about that!
cheers,
m
El Wed, 01-09-2010 a las 07:57 -0500, Mikus Grinbergs escribió:
the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
I recommend rebasing on the geode driver 2.11.9, which was just released by upstream. I've been testing it in Dextrose for about 3 weeks: it fixes all the known rendering bugs and has no regressions.
The XO-1 os1 build already has xorg-x11-drv-geode-2.11.9-1.fc14.olpc1
This package is not in Fedora's git, though. I'll ask Dave Arlie if it's ok with him to update the package. I'm sure he'll be glad to hand-off this driver to someone who can actually test it.
Disclaimer: I am not asking for help; I am just sharing my experiences
I don't have an Access Point - instead, I mainly use ethernet for connectivity. Way back with Joyride builds, sometimes it was the ethernet instead of the radio that got assigned as interface 'eth0'. For consistency, I ended up manually editing 70-persistent-net.rules to ensure that my ethernet got assigned the 'eth1' interface name.
The F14 developers' build assigns the radio as interface 'wlan0'. Thereby, it is my ethernet that gets assigned interface name 'eth0'.
mikus
On Wed, Sep 01, 2010 at 02:03:40PM -0500, Mikus Grinbergs wrote:
The F14 developers' build assigns the radio as interface 'wlan0'. Thereby, it is my ethernet that gets assigned interface name 'eth0'.
Yes, irritating isn't it?
The "disable keyboard and mouse in ebook mode" discussion in #9180 reminds me that in ebook mode the XO in effect has only 8 "pressable inputs" (not counting combinations of presses). That limits the number of actions the user can command (without going to menus).
Other devices have doubled the number of functions per "pressable input" by taking into account duration -- a brief PRESS invokes one action, a prolonged HOLD invokes a different action. The idea of duration was advanced 3 years ago (e.g., #2249), but seems to have been dropped.
I sure wish that implementing "what gets done depends upon how long the button is pressed" (at least for the four buttons on the right) would be revisited. That would improve the usability of the XO as ebook reader.
mikus
Disclaimer: I am not asking for help. I am sharing my experiences:
Running the latest Firefox 4.0 beta with the latest Adobe "square" flash plugin on a slightly overclocked xo-1, youtube at 240p is getting closer to being watchable. With Browse-108, rendering is slightly "jerkier".
mikus
XO-1 os852 (with updated olpc-powerd)
DISCLAIMER: This is FYI - I'm sharing my experiences
While troubleshooting a problem I have on os852 xo1 (interface eth0 disappears), I saw strange output from 'olpc-xos -avahi' on a system where eth0 worked (I was using this other system for eth0 comparison):
0 [~]$ olpc-xos -avahi Time : 06:44:24
06f4a0b5@Lauva 192.168.1.27 Lauva-8 55c4ac9e@Purvs fe80::210:60ff:fe15:41dc Purvs-1 2733b01e@Uguns 192.168.1.16 Uguns-1 112767ef@Zemes 169.254.9.44 Zemes-1 112767ef@Zemes 192.168.1.18 Zemes-1 0 [~]$
The listing for Zemes (taken on Zemes) is slightly confusing - there are two entries. The one (192...) is for its wired ethernet connection, and the other (169...) is for the automatically-started mesh connection. Does OLPC expect an XO to have only one IP-address ?
The listing for Purvs is the one I think is inappropriate. Apparently, Purvs at this time did not have its ethernet software (IPv4) address set - so its ethernet-hardware-derived (IPv6) address got shown. [I do __NOT__ use IPv6 addresses to communicate between XOs.] A little later, Purvs had set up its IPv4 ethernet address (I forget - was that manual, or automatic ?) - now repeating 'olpc-xos -avahi' at Zemes resulted in the appropriate (192...) address for Purvs being reported.
mikus
On Sun, 2010-10-17 at 08:37 -0500, Mikus Grinbergs wrote:
XO-1 os852 (with updated olpc-powerd)
DISCLAIMER: This is FYI - I'm sharing my experiences
While troubleshooting a problem I have on os852 xo1 (interface eth0 disappears),
You're probably seeing this bug:
After a very long chase, we fixed it for good in Dextrose by disabling mesh support:
http://dev.laptop.org/ticket/10195
Besides this particular bug, we could never get the mesh to work reliably on the XO-1, and at this point I don't believe it will ever happen. The ad-hoc mode covers 99% of the real-world use-cases for the mesh, using a mature, standard protocol.
While troubleshooting a problem I have on os852 xo1 (interface eth0 disappears),
You're probably seeing this bug: http://dev.laptop.org/ticket/10195 After a very long chase, we fixed it for good in Dextrose by disabling mesh support:
Yes - the symptom looks the same (though I havent seen "USB disconnect")
The environment I have in mind as my "ideal deployment", though, is "under the tree" where a number of XO-1 machines are running Fedora9-based builds. I think it would be difficult to persuade their owners to all consent to upgrade to a build which supports ad-hoc. Yet owners who did upgrade will want to collaborate with owners who did not.
I am having very good luck running mesh on all kinds of XO-1 builds in my own environment (which connects to an access point through wired ethernet). Thus it came as a surprise to me that when I tested in a different environment (which connects to an access point through wireless), that eth0 would disappear on os852-xo1 with October RPMs. [Back in September, os852-xo1 in that environment kept its eth0.]
[Note - I have no difficulty running/using eth0 (or connecting to the AP) if I __manually__ set it up it from the command line -- it is only that Sugar now does not show Access Point icons in Neighborhood View.]
For the time being, I will continue to investigate this "eth0 disappears" situation - and will even write an os852 ticket if I find something defective. Regarding my "ideal deployment", I suspect it might be easier to "back" the os852-xo1 build to keep using mesh, than to "forward" previous-year XO-1 owners to start using ad-hoc.
mikus
DISCLAIMER: I am not asking for help; I am just sharing my thoughts.
I've been testing XO-1 with builds prior to 2010. And what I've often noticed, in looking first thing (after booting) at Neighborhood View:
XO-icons appear (seen via mesh). Very soon, these icons disappear.
The circular mesh-icons pulse - eventually mesh-1 is brought up XO-icons appear (seen via mesh).
It is as though this just-started XO-1 system was happy to receive radio signals from other XOs -- but then was told "forget about all that" -- and had to go through a protracted "find what frequency to use" procedure to again establish contact with other XOs on the air.
----
It seems to me -- if the just-started XO (any model) is *already* receiving identity information off the air - why BREAK that connection ?
The just-started XO should initially set its frequency to be the same as it was whenever that XO was last used. If at least one *other* radio signal is heard, it should leave that frequency connected -- and depend on the user to intervene (through Neighborhood View) if now this XO should instead be connected to a different station (or frequency).
[If there happens to be an user who would prefer the automatic connection to be to the "first ever used" access point (first entry in ~/.sugar/default/nm/connections.cfg), rather than to the "last ever used" access point -- provide a gconf flag setting that keeps the existing connections.cfg usage (it overrides last used connectivity).]
The "automatically started by the hardware" (i.e., "first thing" I saw) radio setup should be RESET only if it is on a different frequency than the access point (or non-access point) the XO is expected to reconnect to. I believe that AVOIDING the "reset the radio, and set up the frequency anew for the connection I am looking for" procedure will save a lot of time in the majority of cases.
mikus
The new (dotted version) Browse in 10.1.3. build 353 (on XO-1) omits 'application/pdf' from its listed mimetypes. Is this intentional ?
mikus
Booted ok on XO-1. At its current level, this system is already usable. [Was even able to apply my customizations, except for doing editing.]
In Terminal, cursor movement keys don't work. [I also saw interference to Terminal (white background) from dmesg? lines (black background), after each boot -- but these would go away if I just restarted Sugar.]
Could not use text console (alt-ctl-Fn combo appears to be ignored).
Came up with ad-hoc network on channel 1 (interface wlan0). I stopped that, started mesh manually, made sure mesh multicast was active, was able to transfer files with rsync (via mesh) between XO-1 systems.
Was able to run a number of Activities. The bowdlerized Speak refused to answer some of my questions. Record never crashed - not even in 'High' quality on XO-1. Among the non-starters were Chat and TamTam.
The 'My Settings' XO-color choice will be nice, once I figure it out.
Multimedia o.k. Never had Sugar crash in several hours running XO-1.
Thank you muchly for your great leap forward, mikus
El Wed, 01-09-2010 a las 05:03 -0500, Mikus Grinbergs escribió:
In Terminal, cursor movement keys don't work. [I also saw interference to Terminal (white background) from dmesg? lines (black background), after each boot -- but these would go away if I just restarted Sugar.]
This could be X using the xfree86 keycodes instead of the evdev ones. What does "setxkbmap -v" say?
Could not use text console (alt-ctl-Fn combo appears to be ignored).
Same XKB misconfiguration, prolly.
Among the non-starters were Chat and TamTam.
Could you determine why? They do work with Sugar 0.88 on F11. So probably we have ABI issues in Fedora 14.
(suppressed rant about Sugar not using a proper packaging system)
Thank you muchly for your great leap forward, mikus
Thank you very much for all the testing you've been doing.
In Terminal, cursor movement keys don't work. [I also saw interference to Terminal (white background) from dmesg? lines (black background), after each boot -- but these would go away if I just restarted Sugar.]
This could be X using the xfree86 keycodes instead of the evdev ones. What does "setxkbmap -v" say?
0 [olpc]# setxkbmap -v Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols: pc+us(olpc)+inet(evdev)+terminate(ctrl_alt_bksp) geometry: pc(pc104) 0 [olpc]#
By the way, in Terminal 'vi' appears to be placing the text it shows onto a NON-EMPTY screen - there is present background text from what had in the past been shown on the Terminal screen. If I want to look at something, I now use 'cat' (which has blank background) instead of 'vi'.
Among the non-starters were Chat and TamTam.
Could you determine why?
Activity output logs attached. Chat fails because no attribute _pservice. TamTam (all) crash. (shell.log excerpt attached) 'dmesg' says:
TamTamMini <20c[1374]: segfault at b4bcd0 ip b665c4c2 sp bffa6250 error 7 in aclient.so[b6659000+b000]
mikus
p.s. I don't know if this is from my own customization, or if it came in the build -- but now Telepathy uses "accounts" within salut -- with the consequence that sometimes other systems are told the account's nickname for the system, instead of the nickname I specified to Sugar.
On 09/02/2010 07:43 PM, Mikus Grinbergs wrote:
In Terminal, cursor movement keys don't work. [I also saw interference to Terminal (white background) from dmesg? lines (black background), after each boot -- but these would go away if I just restarted Sugar.]
This could be X using the xfree86 keycodes instead of the evdev ones. What does "setxkbmap -v" say?
0 [olpc]# setxkbmap -v Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols: pc+us(olpc)+inet(evdev)+terminate(ctrl_alt_bksp) geometry: pc(pc104) 0 [olpc]#
By the way, in Terminal 'vi' appears to be placing the text it shows onto a NON-EMPTY screen - there is present background text from what had in the past been shown on the Terminal screen. If I want to look at something, I now use 'cat' (which has blank background) instead of 'vi'.
Among the non-starters were Chat and TamTam.
Could you determine why?
Activity output logs attached. Chat fails because no attribute _pservice.
This has been fixed in git:
http://git.sugarlabs.org/projects/chat/repos/mainline/commits/997ca380edbc59...
Aleksey will do a new release.
Regards, Simon
Chat fails because no attribute _pservice.
This has been fixed in git:
http://git.sugarlabs.org/projects/chat/repos/mainline/commits/997ca380edbc59...
With that change applied on an XO-1 system to the Chat-66 on os1, I was able to collaborate with an XO-1 system running Chat-66 on os604dx, plus an XO-1 system running Chat-65 on os856, plus an XO-1 system running Chat-48 on build 802 -- that's a four-way-chat collaboration, using regular mesh, NOT ad-hoc. [By the way, Chat on the os604dx system still worked, even after I applied the pippy_apps.py fix there, as well.]
mikus
On Sat, 2010-09-11 at 16:47 -0500, Mikus Grinbergs wrote:
With that change applied on an XO-1 system to the Chat-66 on os1, I was able to collaborate with an XO-1 system running Chat-66 on os604dx, plus an XO-1 system running Chat-65 on os856, plus an XO-1 system running Chat-48 on build 802 -- that's a four-way-chat collaboration, using regular mesh, NOT ad-hoc. [By the way, Chat on the os604dx system still worked, even after I applied the pippy_apps.py fix there, as well.]
Out of curiosity... what's build os604dx? :-)
Disclaimer: I am not asking for help; I am just sharing my experience.
I noticed - perhaps because of the Sugar 0.90 'Remove_Presence_Service' feature - THREE separate icons in F14 Neighborhood for one-and-the-same XO-1 system (which runs os852). Admittedly, that system can be simultaneously accessed from the F14 system via TWO different IP addresses (192.168.1.16 on ethernet, plus 169.254.8.104 on mesh) -- but three separate Neighborhood icons for that single system seem excessive.
For now, please don't file bugs unless you include patches.
I'll wait until bugs without patches are acceptable. And I need to be able to recreate the situation - I don't know how easy that will be.
mikus
For now, please don't file bugs unless you include patches.
I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ?
For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14.
mikus
On 4 September 2010 03:24, Mikus Grinbergs mikus@bga.com wrote:
For now, please don't file bugs unless you include patches.
I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ?
Because nobody other than me is fixing the problems right now, and the bugs will go stale. And if someone is available to fix bugs, you only have to spend 5 minutes working with the image to encounter several of them. A bug tracker is needless overhead for such early and "loose" development.
This of course will change with time, if the project continues to progress.
For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14.
As this is a topic purely related to Sugar you are welcome to file a bug on the SL bug tracker, or start a discussion on the sugar mailing list.
I should also clarify that if you have an easy solution for a bug (such as: add package XYZ) you are welcome to file a bug - by "only file bugs with patches" I guess I meant "only file bugs with patches or simple solutions"
I'm just trying to focus and organize the OS-level work, and to avoid wasting time on bug tracking in this early stage. Thanks for working with me on this...
Daniel
On Sat, Sep 4, 2010 at 3:56 PM, Daniel Drake dsd@laptop.org wrote:
On 4 September 2010 03:24, Mikus Grinbergs mikus@bga.com wrote:
For now, please don't file bugs unless you include patches.
I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ?
Because nobody other than me is fixing the problems right now, and the bugs will go stale. And if someone is available to fix bugs, you only have to spend 5 minutes working with the image to encounter several of them. A bug tracker is needless overhead for such early and "loose" development.
Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack.... does that not count :-(
This of course will change with time, if the project continues to progress.
For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14.
As this is a topic purely related to Sugar you are welcome to file a bug on the SL bug tracker, or start a discussion on the sugar mailing list.
No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14
I should also clarify that if you have an easy solution for a bug (such as: add package XYZ) you are welcome to file a bug - by "only file bugs with patches" I guess I meant "only file bugs with patches or simple solutions"
I'm just trying to focus and organize the OS-level work, and to avoid wasting time on bug tracking in this early stage. Thanks for working with me on this...
Daniel _______________________________________________ olpc mailing list olpc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc
El Sun, 05-09-2010 a las 00:53 +0100, pbrobinson@gmail.com escribió:
Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack.... does that not count :-(
Such parallel efforts are indeed mutually beneficial.
Dextrose also enjoyed the pioneering packaging and testing effort carried on on 0.88 by the SoaS folks, plus the platform stabilization work done by dsd, pgf and cjb.
Isn't this the normal thing in FLOSS development?
No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14
Done, but I'm afraid I had to give it negative karma:
---cut--- Traceback (most recent call last): File "/usr/bin/sugar-activity", line 21, in <module> main.main() File "/usr/lib/python2.7/site-packages/sugar/activity/main.py", line 115, in main module = __import__(module_name) File "/home/bernie/Activities/Read.activity/readactivity.py", line 25, in <module> import evince ImportError: /usr/lib64/python2.7/site-packages/gtk-2.0/evince.so: undefined symbol: ev_selection_get_selection_map Exited with status 1, pid 5410 data (None, <open file '<fdopen>', mode 'w' at 0x261a150>, 'c9a33f84910d7499496f16cb75f4a930a1f234d4') ---cut---
On Sun, Sep 5, 2010 at 10:57 AM, Bernie Innocenti bernie@codewiz.org wrote:
El Sun, 05-09-2010 a las 00:53 +0100, pbrobinson@gmail.com escribió:
Well I am for SoaS related things which while isn't XO hardware related it does affect everything further up the stack.... does that not count :-(
Such parallel efforts are indeed mutually beneficial.
Dextrose also enjoyed the pioneering packaging and testing effort carried on on 0.88 by the SoaS folks, plus the platform stabilization work done by dsd, pgf and cjb.
Isn't this the normal thing in FLOSS development?
No point as its directly Fedora related but if people could add positive karma to this it would be fixed quicker, else in about 4-5 days it will head to F-14 stable. https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14
Done, but I'm afraid I had to give it negative karma:
Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue
http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af...
Peter
El Mon, 06-09-2010 a las 11:49 +0100, pbrobinson@gmail.com escribió:
Done, but I'm afraid I had to give it negative karma:
Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue
http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af...
To keep the testing cycle shorter, couldn't you just build the rpms locally and test them once on your system before pushing them to bodhi?
On Mon, Sep 6, 2010 at 10:46 PM, Bernie Innocenti bernie@codewiz.org wrote:
El Mon, 06-09-2010 a las 11:49 +0100, pbrobinson@gmail.com escribió:
Done, but I'm afraid I had to give it negative karma:
Looking at the upstream GIT of evince it looks like this is another of the apis that have been deprecated upstream and Read needs to be updated to fix the issue
http://git.gnome.org/browse/evince/diff/libdocument/ev-selection.h?id=18d2af...
To keep the testing cycle shorter, couldn't you just build the rpms locally and test them once on your system before pushing them to bodhi?
I don't maintain that package. I also don't maintain Read. The gnome-python2 package I did update was just re-enabling the upstream. In that regard i did test the gnome-python2 package but but not against Read as where I was in the world at the time I didn't have a working F-14 system to hand with X working so its pretty hard to. At the moment I've worked every day in the last month and I've being travelling around Europe at least once a week so I'm battling to have time to do the basic stuff.... and I didn't believe I'm the only person in the sugar testing world.
The problem isn't evince or gnome-python2 but that Read needs to be updated again for the new upstream evince api changes (again). Looking in Read git the last tagged release is Read 79 yet on a.sl.o is Read 86. I'm not sure what the rest of the changes are or which version is correct so going on the official Read 79 release it wouldn't work any way.
Peter
On 6 September 2010 15:59, pbrobinson@gmail.com pbrobinson@gmail.com wrote:
The problem isn't evince or gnome-python2 but that Read needs to be updated again for the new upstream evince api changes (again).
You're right in that Read changes are needed, but there is already a git tree floating around with such changes (that still need a bit of work).
However the problem that Bernie pointed out is different, and will continue to occur even after updating Read. The file installed by gnome-python2-evince is broken. that is, the following simple command will fail: python -c 'import evince' It is probably a bug in the upstream code.
Daniel
El Mon, 06-09-2010 a las 22:59 +0100, pbrobinson@gmail.com escribió:
I don't maintain that package. I also don't maintain Read. The gnome-python2 package I did update was just re-enabling the upstream. In that regard i did test the gnome-python2 package but but not against Read as where I was in the world at the time I didn't have a working F-14 system to hand with X working so its pretty hard to. At the moment I've worked every day in the last month and I've being travelling around Europe at least once a week so I'm battling to have time to do the basic stuff.... and I didn't believe I'm the only person in the sugar testing world.
Sorry, didn't mean to sound like I did not appreciate your packaging work. Let me know how I could help, besides testing (although I'm also spreading myself very thin, as you know).
The problem isn't evince or gnome-python2 but that Read needs to be updated again for the new upstream evince api changes (again). Looking in Read git the last tagged release is Read 79 yet on a.sl.o is Read 86. I'm not sure what the rest of the changes are or which version is correct so going on the official Read 79 release it wouldn't work any way.
Sayamindu may know.
For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14.
As this is a topic purely related to Sugar you are welcome to file a bug on the SL bug tracker, or start a discussion on the sugar mailing list.
Daniel - I deliberately posted to fedora-olpc-list with a hard-to-pin-down situation (in hopes that someone other than you would read it). The error in this case (shown in the log attached to my post) is "ImportError: /usr/lib/python2.7/site-packages/gtk-2.0/evince.so: undefined symbol: ev_selection_get_selection_map".
I expect that Sugar's invocation ('import evince') has not changed since F11, where it works. But the called 'evince.so' module is smaller in F11 (and has other install dependencies), whereas it has grown to three times that size in F14. Is it kosher to file a bug against Sugar because something *called* by Sugar has (in the version fetched by 'yum' when running build os1) a problem in F14 ? I don't know the answer.
nobody other than me is fixing the problems right now
Bummer. I do think that problems with the 'evince.so' that came from an F14 yum repository ought to be off your radar.
I'm just trying to focus and organize the OS-level work, and to avoid wasting time on bug tracking in this early stage.
My question assumed that if a symptom shows up in 'Object Chooser' in 0.90 (which the XO-1 installs with F14), then "bug tracking" would not need to be performed SEPARATELY for F14 than the "bug tracking" already being done for 0.84 (which is included in, say, Milestone 10.0.3).
If nobody other than you looks at things uncovered in os1 but unrelated to "construction of an F14 build that will run on the XO" -- then I guess I would describe their attitude as "problems are real only if they show up in 'officially released' builds". Oh well.
mikus
p.s. My most obvious problem at first with os1 was the inability to use the keyboard arrow keys in 'vi' in Terminal (I switched to using the hjkl keys instead); plus the presence of garbage text in the background of the 'vi' screen. Also, I couldn't get to a text console.
Eventually, I went into 'My Settings' -> 'Keyboard' and specified a more appropriate keyboard model. That seemed to "activate" the <ctl-alt-Fn> sequence that allows me to get into a text console -- and now in a text console 'vi' works properly with os1.
On Sat, Sep 4, 2010 at 10:24 AM, Mikus Grinbergs mikus@bga.com wrote:
For now, please don't file bugs unless you include patches.
I can understand not wanting bug reports against items which OLPC/Sugar are still in the process of changing. But why defer reporting problems which might not be addressed unless there was a report ?
For instance, Read-87 fails to launch on XO-1 os1 (F14) when it tries to 'import evince'. Though the necessary gnome-python2-evince package was not included in the os1 build, when I manually install that package from the yum Fedora-14 repositories, the import statement still fails -- apparently because the evince.so module provided by the current Fedora-14 package has internal inconsistencies. I myself do not have a Python test case which does 'import evince' - nor do I have a patch - but perhaps the maintainers of the Read Activity might want to discuss this situation with the maintainers of Python on Fedora 14.
This is a known problem with Read at the moment. I fixed the package the other day and its filtering through the updates-testing. There's a number of fairly large number of issues with Fedora 14 at the moment due to the new systemd and python 2.7 not to mention some quite big gnome related changes. We're preparing the SoaS 4 release based on this as well so the SoaS team are aware of a number of issues and we're working as quickly as possible to fix them (but the 3 people in the team are also very busy with other life related things as well) and this will benefit this release as well because both teams can work towards the same goal.
Regards, Peter
On 09/01/2010 07:22 AM, Daniel Drake wrote:
Hi,
Hi Daniel,
first of all - thanks for your excellent work!
After seeing the community help significantly with F11-on-XO development, I'm wondering if we can do something similar for a future release. So, I've taken the first few steps in getting OLPC's technologies rebased on Fedora 14 and Linux v2.6.35.
The result has lots of problems, but I figure that publishing the work so far is the first step in getting things fixed.
Things are in such an early stage that I'm labelling this as a developers-only release. To name a few: Sugar crashes all the time, the XO-1.5 camera doesn't work, there are some funky graphics bugs on XO-1, no power management, DCON doesn't work right on either laptop, desktop switching lands you at a blank screen.
For now, please don't file bugs unless you include patches. And, to take 1 bite at a time out of this huge task, lets ignore all but the biggest sugar issues for now because there is plenty of OS work to be done first. (or alternatively lets take sugar issues directly to SL trac)
And the links: 2.6.35 kernel is in git://dev.laptop.org/olpc-2.6 branch olpc-2.6.35 OS build is done from 'f14' branch of olpc-os-builder First released images are at http://build.laptop.org/F14/os1/ Trac is at http://dev.laptop.org/milestone/F14 (basically my immediate TODO), please don't file tickets unless you include patches in these early days
Note: I haven't tested those exact images (since Chris @ OLPC built them), so boot-testing them can be the first task for someone. I have been working from the same codebases making local images successfully, so they will probably work (to the extent that things are working).
The XO-1.0 build does boot fine here. After installing the latest sugar package [1] I get quite good results. This is very promising. Yay!!!
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
Regards, Simon
[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=193501
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it. Since I am running it from an SDHC card I manually extracted the filesystems onto the card. I have an updated kernel rpm that fixes a few of initial bugs that needed squashing with the XO 1.5. I can post that if people want to do extended testing.
That error looks like OFW is not finding a bootable device. What output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
On 09/11/2010 04:20 PM, Jon Nettleton wrote:
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it. Since I am running it from an SDHC card I manually extracted the filesystems onto the card. I have an updated kernel rpm that fixes a few of initial bugs that needed squashing with the XO 1.5. I can post that if people want to do extended testing.
Sure! Keep it rolling :)
That error looks like OFW is not finding a bootable device. What output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
Thanks Jon for following up and sharing the command. It helped to find out that the bootfw package was missing. Daniel will do a new build.
Regards, Simon
On 09/11/2010 04:56 PM, Simon Schampijer wrote:
On 09/11/2010 04:20 PM, Jon Nettleton wrote:
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it. Since I am running it from an SDHC card I manually extracted the filesystems onto the card. I have an updated kernel rpm that fixes a few of initial bugs that needed squashing with the XO 1.5. I can post that if people want to do extended testing.
Sure! Keep it rolling :)
That error looks like OFW is not finding a bootable device. What output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
Thanks Jon for following up and sharing the command. It helped to find out that the bootfw package was missing. Daniel will do a new build.
Regards, Simon
As a quick heads up. I just built an image for XO-1.5 with the latest development branch (f14). Booted fine. Thanks Daniel!
More to come, Simon
On 09/22/2010 06:24 PM, Simon Schampijer wrote:
On 09/11/2010 04:56 PM, Simon Schampijer wrote:
On 09/11/2010 04:20 PM, Jon Nettleton wrote:
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it. Since I am running it from an SDHC card I manually extracted the filesystems onto the card. I have an updated kernel rpm that fixes a few of initial bugs that needed squashing with the XO 1.5. I can post that if people want to do extended testing.
Sure! Keep it rolling :)
That error looks like OFW is not finding a bootable device. What output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
Thanks Jon for following up and sharing the command. It helped to find out that the bootfw package was missing. Daniel will do a new build.
Regards, Simon
As a quick heads up. I just built an image for XO-1.5 with the latest development branch (f14). Booted fine. Thanks Daniel!
More to come, Simon
I uploaded a new XO-1.5 build (2GB with reduced set of activities) at [1]. An issue I know of is that when booting you do not get into Sugar, the booting screen stays on. Restarting X ctrl+alt+erase will work. There are also some other bugs I have filed today [2] [3].
If you are sure that a bug is in 0.90 and not due to the XO platform you can file it in the tracker [4]. Please make sure to leave a note where you found the bug that we can treat it accordingly.
Of course, this is a development build I do to find and fix 0.90 bugs on F14. Please treat it as well like that :)
Regards, Simon
[1] http://dev.laptop.org/~erikos/F14_builds/ [2] http://bugs.sugarlabs.org/ticket/2291 [3] http://bugs.sugarlabs.org/ticket/2363 [4] http://bugs.sugarlabs.org
I uploaded a new XO-1.5 build (2GB with reduced set of activities) at http://dev.laptop.org/~erikos/F14_builds/
If you are sure that a bug is in 0.90 and not due to the XO platform you can file it in the tracker
I've been reasonably happily running build os1 (F14) on the XO-1, and updating it as RPMs become available (I'm now using sugar 0.89.10-1).
I'd appreciate it if a XO-1 F14 build were available with which it was permitted for me to file system-behavior bugs.
mikus
On 09/23/2010 06:59 PM, Mikus Grinbergs wrote:
I uploaded a new XO-1.5 build (2GB with reduced set of activities) at http://dev.laptop.org/~erikos/F14_builds/
If you are sure that a bug is in 0.90 and not due to the XO platform you can file it in the tracker
I've been reasonably happily running build os1 (F14) on the XO-1, and updating it as RPMs become available (I'm now using sugar 0.89.10-1).
Yes, it works fine so far.
I'd appreciate it if a XO-1 F14 build were available with which it was permitted for me to file system-behavior bugs.
We will get there at one point.
Regards, Simon
On 09/23/2010 05:01 PM, Simon Schampijer wrote:
On 09/22/2010 06:24 PM, Simon Schampijer wrote:
On 09/11/2010 04:56 PM, Simon Schampijer wrote:
On 09/11/2010 04:20 PM, Jon Nettleton wrote:
The XO-1.5 build does not boot for me, I get the following after flashing the image:
Boot device: /wlan Argumenst: Scan for: OLPCOFW not found Scan for: school-mesh-0 not found Scan for: school-mesh-1 not found Scan for: school-mesh-2 not found buffer@ff83b080:0: Can't open boot device
Anyone else booted the XO-1.5 image already?
I have booted the XO-1.5 image but did not use OFW to install it. Since I am running it from an SDHC card I manually extracted the filesystems onto the card. I have an updated kernel rpm that fixes a few of initial bugs that needed squashing with the XO 1.5. I can post that if people want to do extended testing.
Sure! Keep it rolling :)
That error looks like OFW is not finding a bootable device. What output do you get if you do dir int:\boot\ from the OFW prompt?
-Jon
Thanks Jon for following up and sharing the command. It helped to find out that the bootfw package was missing. Daniel will do a new build.
Regards, Simon
As a quick heads up. I just built an image for XO-1.5 with the latest development branch (f14). Booted fine. Thanks Daniel!
More to come, Simon
I uploaded a new XO-1.5 build (2GB with reduced set of activities) at [1]. An issue I know of is that when booting you do not get into Sugar, the booting screen stays on. Restarting X ctrl+alt+erase will work. There are also some other bugs I have filed today [2] [3].
If you are sure that a bug is in 0.90 and not due to the XO platform you can file it in the tracker [4]. Please make sure to leave a note where you found the bug that we can treat it accordingly.
Of course, this is a development build I do to find and fix 0.90 bugs on F14. Please treat it as well like that :)
Regards, Simon
I have uploaded now as well a build for the XO-1 [1] (which does not have the issue with the booting screen described above). I disabled the Sugar Ad-hoc networks and set the gconf option /desktop/sugar/user/default_nick to 'disabled' in order to allow to set the nick on the startup screen.
Regards, Simon
I need to add two drivers for external USB devices to os852.
I believe that creating a complete build from scratch for the XO-1, which includes the drivers I want, ought to work -- but I'm intimidated at jumping into git and kernel-building, just for a couple of drivers. [Besides, I don't want to be in the business of build maintenance.]
So far, I'm trying to see if I can compile those drivers from source -- but I'm having a HUGE struggle with the deficiencies of XO-1 package kernel-devel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586 (it's missing header directories: 'arch/x86/include', 'include/trace', and 'include/asm-x86').
But even when I've managed to compile the most recently available driver source and gotten an output module, 'modprobe' gives me "unknown symbol" errors, like the following (as logged in dmesg): [139115.158397] uvcvideo: disagrees about version of symbol v4l_compat_translate_ioctl [139115.158424] uvcvideo: Unknown symbol v4l_compat_translate_ioctl [139115.163353] uvcvideo: disagrees about version of symbol video_devdata [139115.163377] uvcvideo: Unknown symbol video_devdata [139115.168912] uvcvideo: disagrees about version of symbol video_unregister_device [139115.168932] uvcvideo: Unknown symbol video_unregister_device [139115.170160] uvcvideo: disagrees about version of symbol video_device_alloc [139115.170160] uvcvideo: Unknown symbol video_device_alloc [139115.170160] uvcvideo: disagrees about version of symbol video_register_device [139115.170160] uvcvideo: Unknown symbol video_register_device [139115.170160] uvcvideo: disagrees about version of symbol video_usercopy [139115.170160] uvcvideo: Unknown symbol video_usercopy [139115.170160] uvcvideo: disagrees about version of symbol video_device_release [139115.170160] uvcvideo: Unknown symbol video_device_release
And if I try to import the driver from (for instance) kernel-2.6.31.9-174.fc12.i686.rpm (the driver is in Fedora builds) into kernel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586 (the driver is NOT in olpc builds) - I get "Invalid module format" from the os852 modprobe, even if I invoke it with 'modprobe --force'.
I'm asking that someone please tell me which Fedora kernel package comes closest to the XO-1 os852 kernel package - so I can go exploring for differences. I also suspect that the driver source code I used is not the same as the driver source code Fedora used -- do I have to look in Fedoraproject git for the driver source code to try to compile ?
Thanks - help would be greatly appreciated, mikus
Mikus did you apply the patch in http://dev.laptop.org/ticket/10297 in the kernel_xo1.spec? It solves the asm issue. Patch, recompile the kernel install it (including headers and devel) and recompile your driver. No other kernel comes close to OLPCs :-)
--- On Wed, 9/29/10, Mikus Grinbergs mikus@bga.com wrote:
From: Mikus Grinbergs mikus@bga.com Subject: Request for help with adding a driver to build os852 To: "Chris Ball" cjb@laptop.org Cc: "OLPC Devel" devel@lists.laptop.org, "fedora-olpc-list" fedora-olpc-list@redhat.com Date: Wednesday, September 29, 2010, 11:46 AM I need to add two drivers for external USB devices to os852.
I believe that creating a complete build from scratch for the XO-1, which includes the drivers I want, ought to work -- but I'm intimidated at jumping into git and kernel-building, just for a couple of drivers. [Besides, I don't want to be in the business of build maintenance.]
So far, I'm trying to see if I can compile those drivers from source -- but I'm having a HUGE struggle with the deficiencies of XO-1 package kernel-devel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586 (it's missing header directories: 'arch/x86/include', 'include/trace', and 'include/asm-x86').
But even when I've managed to compile the most recently available driver source and gotten an output module, 'modprobe' gives me "unknown symbol" errors, like the following (as logged in dmesg): [139115.158397] uvcvideo: disagrees about version of symbol v4l_compat_translate_ioctl [139115.158424] uvcvideo: Unknown symbol v4l_compat_translate_ioctl [139115.163353] uvcvideo: disagrees about version of symbol video_devdata [139115.163377] uvcvideo: Unknown symbol video_devdata [139115.168912] uvcvideo: disagrees about version of symbol video_unregister_device [139115.168932] uvcvideo: Unknown symbol video_unregister_device [139115.170160] uvcvideo: disagrees about version of symbol video_device_alloc [139115.170160] uvcvideo: Unknown symbol video_device_alloc [139115.170160] uvcvideo: disagrees about version of symbol video_register_device [139115.170160] uvcvideo: Unknown symbol video_register_device [139115.170160] uvcvideo: disagrees about version of symbol video_usercopy [139115.170160] uvcvideo: Unknown symbol video_usercopy [139115.170160] uvcvideo: disagrees about version of symbol video_device_release [139115.170160] uvcvideo: Unknown symbol video_device_release
And if I try to import the driver from (for instance) kernel-2.6.31.9-174.fc12.i686.rpm (the driver is in Fedora builds) into kernel-2.6.31_xo1-20100823.1641.1.olpc.12d64069981699a.i586 (the driver is NOT in olpc builds) - I get "Invalid module format" from the os852 modprobe, even if I invoke it with 'modprobe --force'.
I'm asking that someone please tell me which Fedora kernel package comes closest to the XO-1 os852 kernel package - so I can go exploring for differences. I also suspect that the driver source code I used is not the same as the driver source code Fedora used -- do I have to look in Fedoraproject git for the driver source code to try to compile ?
Thanks - help would be greatly appreciated, mikus
olpc mailing list olpc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc
Mikus did you apply the patch in http://dev.laptop.org/ticket/10297 in the kernel_xo1.spec? It solves the asm issue. Patch, recompile the kernel install it (including headers and devel) and recompile your driver.
Mavrothal - my point was that I did not want to have to learn all about git, or all about the mechanics of building the olpc kernel - I figured it would take me weeks to get up to speed with all that.
If I can possibly avoid it, I'd prefer to not touch the kernel_xo1.spec myself. Does the #10297 patch fix the missing 'include/trace' as well ?
mikus
p.s. Note that my problem concerns adding two drivers to os852. If I install my own kernel, how do I "backport" the drivers from my kernel to os852 ?
Mikus if you driver does not compile agains the od852 kernel, you must change the kernel! Get the os852 kernel srpm, patch it, compile the kernel rpms (should be the same kernel as the os852 but with corrected kerneel-devel) install it, build your driver against this kernel and then see if this driver will work with the original os852 kernel. You may need to force it but it should, I think.
I did not come across the include/trace problem so I do not know if the patch fixes it.
--- On Wed, 9/29/10, Mikus Grinbergs mikus@bga.com wrote:
From: Mikus Grinbergs mikus@bga.com Subject: Re: Request for help with adding a driver to build os852 To: "Yioryos Asprobounitis" mavrothal@yahoo.com Cc: "Chris Ball" cjb@laptop.org, "OLPC Devel" devel@lists.laptop.org, "fedora-olpc-list" fedora-olpc-list@redhat.com Date: Wednesday, September 29, 2010, 2:50 PM
Mikus did you apply the patch in http://dev.laptop.org/ticket/10297 in the kernel_xo1.spec? It solves the asm issue. Patch,
recompile the kernel
install it (including headers and devel) and recompile
your driver.
Mavrothal - my point was that I did not want to have to learn all about git, or all about the mechanics of building the olpc kernel
- I figured
it would take me weeks to get up to speed with all that.
If I can possibly avoid it, I'd prefer to not touch the kernel_xo1.spec myself. Does the #10297 patch fix the missing 'include/trace' as well ?
mikus
p.s. Note that my problem concerns adding two drivers to os852. If I install my own kernel, how do I "backport" the drivers from my kernel to os852 ?