meta-handheld
Hi all,
I've discussed the possibility with a few people on IRC of creating a meta- handheld layer for support of older handheld devices - this would include Zaurus, iPAQ, SimPad, etc; possibly even EZX phones if they aren't in a layer of their own. These machines share a fair amount of commonality and I don't think that they will all survive if each one has to be put into a BSP of its own. Response so far seems to be positive but I'd like to hear thoughts from others on this.
I have access to many of these devices, and this is something I am prepared to maintain on my own time, although I would appreciate help from others. I have the basis of a layer from what was left in oe-core and meta-extras but quite a lot of it would need to be brought over from OE.
If people agree that this is a good idea, the next question would be where to host it - is this something that could be within the meta-oe repository?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre (UK)
Quoted 10 lines · Paul Eggleton
Hi all,
I've discussed the possibility with a few people on IRC of creating a meta- handheld layer for support of older handheld devices - this would include Zaurus, iPAQ, SimPad, etc; possibly even EZX phones if they aren't in a layer of their own. These machines share a fair amount of commonality and I don't think that they will all survive if each one has to be put into a BSP of its own. Response so far seems to be positive but I'd like to hear thoughts from others on this.
Quoted 8 lines
I have access to many of these devices, and this is something I am prepared to maintain on my own time, although I would appreciate help from others. I have the basis of a layer from what was left in oe-core and meta-extras but quite a lot of it would need to be brought over from OE.
If people agree that this is a good idea, the next question would be where to host it - is this something that could be within the meta-oe repository?
Grabbing all of these barely supported machines into their own layer sounds like a good plan to me.
Id suggest just hosting it on gitorious, if its inside OE then there is the magic assumption from the public that they should work (which is what happens now). Then people get really dissapointed when I tell them getting it to work is likely to be a hard slog.
Graeme
Op 21 apr 2011, om 18:57 heeft Graeme Gregory het volgende geschreven:
Quoted 19 lines · Paul Eggleton
Quoted 10 lines
Hi all,
I've discussed the possibility with a few people on IRC of creating a meta- handheld layer for support of older handheld devices - this would include Zaurus, iPAQ, SimPad, etc; possibly even EZX phones if they aren't in a layer of their own. These machines share a fair amount of commonality and I don't think that they will all survive if each one has to be put into a BSP of its own. Response so far seems to be positive but I'd like to hear thoughts from others on this.
Quoted 8 lines
I have access to many of these devices, and this is something I am prepared to maintain on my own time, although I would appreciate help from others. I have the basis of a layer from what was left in oe-core and meta-extras but quite a lot of it would need to be brought over from OE.
If people agree that this is a good idea, the next question would be where to host it - is this something that could be within the meta-oe repository?
Quoted 7 lines
Grabbing all of these barely supported machines into their own layer sounds like a good plan to me.
Id suggest just hosting it on gitorious, if its inside OE then there is the magic assumption from the public that they should work (which is what happens now). Then people get really dissapointed when I tell them getting it to work is likely to be a hard slog.
I agree with Graeme on the hosting bit. I also have all the devices you mentioned near my desk, so testing should be easy :)
regards,
Koen
Quoted 24 lines · Koen Kooi
Op 21 apr 2011, om 18:57 heeft Graeme Gregory het volgende geschreven:
Quoted 22 lines · Paul Eggleton
Quoted 10 lines
Hi all,
I've discussed the possibility with a few people on IRC of creating a meta- handheld layer for support of older handheld devices - this would include Zaurus, iPAQ, SimPad, etc; possibly even EZX phones if they aren't in a layer of their own. These machines share a fair amount of commonality and I don't think that they will all survive if each one has to be put into a BSP of its own. Response so far seems to be positive but I'd like to hear thoughts from others on this.
Quoted 8 lines
I have access to many of these devices, and this is something I am prepared to maintain on my own time, although I would appreciate help from others. I have the basis of a layer from what was left in oe-core and meta-extras but quite a lot of it would need to be brought over from OE.
If people agree that this is a good idea, the next question would be where to host it - is this something that could be within the meta-oe repository?
Grabbing all of these barely supported machines into their own layer sounds like a good plan to me.
Quoted 6 lines
Quoted 4 lines
Id suggest just hosting it on gitorious, if its inside OE then there is the magic assumption from the public that they should work (which is what happens now). Then people get really dissapointed when I tell them getting it to work is likely to be a hard slog.
I agree with Graeme on the hosting bit. I also have all the devices you mentioned near my desk, so testing should be easy :)
I'm going to disagree, this is exactly the kind of layer fragmentation I'd not like to see layers cause. Which website do I go to where I can see a list of layers that exist? Who is going to maintain that list? If its off on gitorious nobody will be able to easily find it.
The easiest solution is if git.openembedded.org or git.yoctoproject.org can host the majority of the meta-* repositories.
Equally, I don't really see why this can't be a specific meta- group in meta-oe. The README can clearly spell out what the expectations of the layer are...
Cheers,
Richard
snip
Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
If people agree that this is a good idea, the next question would be where to host it - is this something that could be within the meta-oe repository?
Grabbing all of these barely supported machines into their own layer sounds like a good plan to me.
Quoted 6 lines
Quoted 4 lines
Id suggest just hosting it on gitorious, if its inside OE then there is the magic assumption from the public that they should work (which is what happens now). Then people get really dissapointed when I tell them getting it to work is likely to be a hard slog.
I agree with Graeme on the hosting bit. I also have all the devices you mentioned near my desk, so testing should be easy :)
I'm going to disagree, this is exactly the kind of layer fragmentation I'd not like to see layers cause. Which website do I go to where I can see a list of layers that exist? Who is going to maintain that list? If its off on gitorious nobody will be able to easily find it.
The easiest solution is if git.openembedded.org or git.yoctoproject.org can host the majority of the meta-* repositories.
Quoted 7 lines
Equally, I don't really see why this can't be a specific meta- group in meta-oe. The README can clearly spell out what the expectations of the layer are...
Cheers,
Richard
I agree with Richard, for keeping it as meta- group.
About expectations, at least for Zaurus I don't see problems: vanilla 2.6.38 kernel, actual udev, imminent move to xorg-xserver if kdrive is finally doomed.
Ipaq's seem suffering more bitrot...
Andrea
Quoted 6 lines · On Saturday 23 April 2011 00:09:38 Andrea Adami wrote:
I agree with Richard, for keeping it as meta- group.
About expectations, at least for Zaurus I don't see problems: vanilla 2.6.38 kernel, actual udev, imminent move to xorg-xserver if kdrive is finally doomed.Ipaq's seem suffering more bitrot...
This is a problem, yes. Most of the iPAQs require 2.6.21-hh which is ancient and unmaintained and as we know presents difficulties with modern udev. Some of the iPAQs will work with mainline but many functions will be unavailable. This is something I hope can be sorted out - surely by now a lot of the "ip blocks" used within iPAQs and other PDAs are now in mainline already and all that's necessary is some plumbing...?
Anyway, I'm concerned that if these machines get pushed out to some random repo it's only going to make things worse. I think we can mitigate the concerns about people rushing in only to find that the level of support for their device is less than they hoped simply by being crystal clear about each device's status in documentation (e.g. a wiki page), something which we have not been good at recently. (Am I volunteering to maintain this information as well? Naturally :) )
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre (UK)
Quoted 15 lines · Paul Eggleton
Quoted 6 lines · On Saturday 23 April 2011 00:09:38 Andrea Adami wrote:
I agree with Richard, for keeping it as meta- group.
About expectations, at least for Zaurus I don't see problems: vanilla 2.6.38 kernel, actual udev, imminent move to xorg-xserver if kdrive is finally doomed.Ipaq's seem suffering more bitrot...
This is a problem, yes. Most of the iPAQs require 2.6.21-hh which is ancient and unmaintained and as we know presents difficulties with modern udev. Some of the iPAQs will work with mainline but many functions will be unavailable. This is something I hope can be sorted out - surely by now a lot of the "ip blocks" used within iPAQs and other PDAs are now in mainline already and all that's necessary is some plumbing...?
Quoted 8 lines
Anyway, I'm concerned that if these machines get pushed out to some random repo it's only going to make things worse. I think we can mitigate the concerns about people rushing in only to find that the level of support for their device is less than they hoped simply by being crystal clear about each device's status in documentation (e.g. a wiki page), something which we have not been good at recently. (Am I volunteering to maintain this information as well? Naturally :) )
we can host it on its own repo and not under meta-openembedded umbrella. As long as it is maintained its good
Quoted 13 lines
Cheers,
Paul--
Paul Eggleton
Intel Open Source Technology Centre (UK)_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core