Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-25 Thread Kirtika Ruchandani

 Also worth noting that we have some Zaurus people around and I/we did look
 at OE
 for Mer but felt that we wanted more compatibility with maemo etc to allow
 access to things like Extras.


@David:
Its probably  *very* premature for me to be speaking at this point about
this - but I fail to understand why stuff like Extras should be a problem
with OE. IMHO, OE is designed to accomodate bringing new packages easily -
making it just a matter writing a small bb recipe - if the distro confs are
well-written.  But as I said, I probably don't get your point because I
haven't reached that  stage in my work as yet.

Regards,

-- 
Kirtika Ruchandani
Sophomore
Computer Science and Engineering
Indian Institute of Technology, Madras
___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-25 Thread Kees Jongenburger
On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani kirt...@gmail.com wrote:
 Also worth noting that we have some Zaurus people around and I/we did look
 at OE
 for Mer but felt that we wanted more compatibility with maemo etc to allow
 access to things like Extras.

 @David:
 Its probably  *very* premature for me to be speaking at this point about
 this - but I fail to understand why stuff like Extras should be a problem
 with OE. IMHO, OE is designed to accomodate bringing new packages easily -
 making it just a matter writing a small bb recipe - if the distro confs are
 well-written.  But as I said, I probably don't get your point because I
 haven't reached that  stage in my work as yet.

Debian's packaging strategy if different from OE's in the sense that
the packaging system is intrusive. Therefore
a good debian packages contains a source .deb package and the
package can be created using debian tools.

Many packages created for Maemo are some mix of proper debian
packages , packages without corresponding sources
and packages that with corresponding sources that can not be
recompiled easily because the source package
was only created as part of the debianisation. If the OE port is to
support the extras packages it needs to support
the binary packages as-is(binary). To be able to do that the OE
build would need to have the same base package names as the Maemo
packages(not such a big problem) but binary compatibility clearly
would not fit in the OE strategy where the packages
can be created for different architectures or optimized for different
processors.

In short it most certainly is hard to achieve this. The easy thing
is to find the sources and create a bb file for it and that is extra
work. So it is hard to make use of all the great packages created to
maemo-proper. Mer is very close to achieving that goal

Greetings





 Regards,

 --
 Kirtika Ruchandani
 Sophomore
 Computer Science and Engineering
 Indian Institute of Technology, Madras

 ___
 maemo-community mailing list
 maemo-community@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-community


___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-25 Thread Jeremiah Foster

On Apr 25, 2009, at 13:34, Kees Jongenburger wrote:

 On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani  
 kirt...@gmail.com wrote:
 Also worth noting that we have some Zaurus people around and I/we  
 did look
 at OE
 for Mer but felt that we wanted more compatibility with maemo etc  
 to allow
 access to things like Extras.

 @David:
 Its probably  *very* premature for me to be speaking at this point  
 about
 this - but I fail to understand why stuff like Extras should be a  
 problem
 with OE. IMHO, OE is designed to accomodate bringing new packages  
 easily -
 making it just a matter writing a small bb recipe - if the distro  
 confs are
 well-written.  But as I said, I probably don't get your point  
 because I
 haven't reached that  stage in my work as yet.

 Debian's packaging strategy if different from OE's in the sense that
 the packaging system is intrusive.

Well, I am not sure I agree with you here. Debian has designed  
packages to be un-intrusive. In fact debian requires pristine upstream  
source and only adds a debian directory. Then you build the deb on  
your system, or it gets built on debian's architecture and you install  
the deb for your architecture, but you can always choose to build from  
source with apt-get source. I don't see how this is intrusive - in  
fact, it is one of the least intrusive types of packaging especially  
compared to an RPM.

 Therefore
 a good debian packages contains a source .deb package and the
 package can be created using debian tools.

The resulting deb package built from source is a binary.


 Many packages created for Maemo are some mix of proper debian
 packages , packages without corresponding sources
 and packages that with corresponding sources that can not be
 recompiled easily because the source package
 was only created as part of the debianisation.

Maemo policy currently does not _require_ sources to accompany a  
binary deb. Perhaps it should require sources to be uploaded with the  
deb?

 If the OE port is to
 support the extras packages it needs to support
 the binary packages as-is(binary). To be able to do that the OE
 build would need to have the same base package names as the Maemo
 packages(not such a big problem) but binary compatibility clearly
 would not fit in the OE strategy where the packages
 can be created for different architectures or optimized for different
 processors.

Not sure what you mean here Kees. Debian supports eight architectures  
officially, no reason why the maemo packages couldn't do the same, at  
least theoretically. We'd have to have the build sources from Nokia  
and a host of architectures to build them on, but still, it could be  
done.

 In short it most certainly is hard to achieve this. The easy thing
 is to find the sources and create a bb file for it and that is extra
 work. So it is hard to make use of all the great packages created to
 maemo-proper. Mer is very close to achieving that goal

Mer is an excellent solution to this problem. Plus it has a hard  
working, dedicated community already with a proven, released product.  
This is what should be supported and extended IMHO.

Jeremiah

___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-25 Thread Kees Jongenburger
On Sat, Apr 25, 2009 at 5:33 PM, Jeremiah Foster
jerem...@jeremiahfoster.com wrote:

 On Apr 25, 2009, at 13:34, Kees Jongenburger wrote:

 On Sat, Apr 25, 2009 at 1:21 PM, Kirtika Ruchandani
 kirt...@gmail.com wrote:
 Also worth noting that we have some Zaurus people around and I/we
 did look
 at OE
 for Mer but felt that we wanted more compatibility with maemo etc
 to allow
 access to things like Extras.

 Debian's packaging strategy if different from OE's in the sense that
 the packaging system is intrusive.

 Well, I am not sure I agree with you here. Debian has designed
 packages to be un-intrusive. In fact debian requires pristine upstream
 source and only adds a debian directory. Then you build the deb on
 your system, or it gets built on debian's architecture and you install
 the deb for your architecture, but you can always choose to build from
 source with apt-get source. I don't see how this is intrusive - in
 fact, it is one of the least intrusive types of packaging especially
 compared to an RPM.

 Therefore
 a good debian packages contains a source .deb package and the
 package can be created using debian tools.

 The resulting deb package built from source is a binary.


 Many packages created for Maemo are some mix of proper debian
 packages , packages without corresponding sources
 and packages that with corresponding sources that can not be
 recompiled easily because the source package
 was only created as part of the debianisation.

 Maemo policy currently does not _require_ sources to accompany a
 binary deb. Perhaps it should require sources to be uploaded with the
 deb?
I would feel even safer if the auto builder was a requirement so we know the
source and binaries match.


 If the OE port is to
 support the extras packages it needs to support
 the binary packages as-is(binary). To be able to do that the OE
 build would need to have the same base package names as the Maemo
 packages(not such a big problem) but binary compatibility clearly
 would not fit in the OE strategy where the packages
 can be created for different architectures or optimized for different
 processors.

 Not sure what you mean here Kees. Debian supports eight architectures
 officially, no reason why the maemo packages couldn't do the same, at
 least theoretically. We'd have to have the build sources from Nokia
 and a host of architectures to build them on, but still, it could be
 done.

Practice however is that developers neither have access to the host platform
(when you are not cross compiling) nor are able to change root components. We
must be talking about different things (Is Cortex-A8 a different arch
in your terms?)


 In short it most certainly is hard to achieve this. The easy thing
 is to find the sources and create a bb file for it and that is extra
 work. So it is hard to make use of all the great packages created to
 maemo-proper. Mer is very close to achieving that goal

 Mer is an excellent solution to this problem. Plus it has a hard
 working, dedicated community already with a proven, released product.
 This is what should be supported and extended IMHO.

Indeed I think that given Mer current approach it has great potential.
so Yes we should
try to support Mer as targeted architecture is that the right term for you? or
do you think Mer and Maemo are the same ?

It this not something to discuss on developers list?

Greetings
___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-24 Thread Kees Jongenburger
On Fri, Apr 24, 2009 at 3:13 PM, David Greaves da...@dgreaves.com wrote:
 Also worth noting that we have some Zaurus people around and I/we did look at 
 OE
 for Mer but felt that we wanted more compatibility with maemo etc to allow
 access to things like Extras.

 There would be a *lot* of work in just repackaging software before you even
 start to hack at any code.

The benefits of having the code really ready to be hacked and ported are huge.
and I therefore really hope I can help on this project. Mer is an
other excellent and
but really different project with more focus on end-user usabilty v.s
core reusability :p

Greetings


 David

 Qole wrote:
 I'm sure this is obvious, but I just want to be sure:

 Please also look at the Mer project, since they are trying to build a
 Maemo system, using only the open source pieces of Maemo. They are
 building their system on Ubuntu, instead of OE, but their project might
 offer insight into the problems you will encounter.

 http://wiki.maemo.org/index.php?title=Mer

 On Wed, Apr 22, 2009 at 3:33 AM, Kirtika Ruchandani kirt...@gmail.com
 mailto:kirt...@gmail.com wrote:

     Hello everyone,

     I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
     integrating Maemo in Open Embedded(OE) by creating a maemo image for
     the N800/N810 in OE.

     The project aim is to get a file-system image of maemo built in OE
     for the N800/N810 with all the Maemo software stack components -
     including the hildon UI environment. The work done for this will
     also include making the platform itself portable - i.e. being able
     to port Maemo components for a device over a given base, say angstrom.

     I will be looking at the Poky port of Maemo, previous work done by
     my mentor Florian Boor on this project, Mamona (which supports N800
     in OE) and Angstrom (to be studied as a base) to go about the
     porting work.


     I am a second year under-graduate student at  Indian Institute of
     Technology, Madras (IIT-M) in India and my IRC and garage nickname
     is rkirti.




     --
     Kirtika Ruchandani
     Sophomore
     Computer Science and Engineering
     Indian Institute of Technology, Madras

     http://www.cse.iitm.ac.in/~rkirti/maemo-oe/
     http://www.cse.iitm.ac.in/%7Erkirti/maemo-oe/

 --
 Don't worry, you'll be fine; I saw it work in a cartoon once...
 ___
 maemo-community mailing list
 maemo-community@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-community

___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-24 Thread Simon Pickering

 This means the compromises inherent in using .ipkg vs .deb hurt more  
  than they help... hence Mer's Ubunutu/OBS decision.

OE can equally build .deb's rather than .ipk's

I used the Maemo target a while back to build a few things (mainly  
Octave and deps) and it was nice and painless, except for the fact  
that some of the main dependencies had slightly different names (which  
can confuse dpkg on the device when you try to install packages after  
these ones).

 I think the OE target is the tighter space of true embedded  
 environments - think
 Qtopia and memory/storage measured in 10s/100s MB.

OE is just meta-data, it can target whatever you want. I agree that  
thus far it as tended to target low memory devices (mainly as that's  
all that has been around thus far).

 Mer, maemo (and hildon) are more aimed at devices (like the internet tablets)
 which have no problems running 'real' OSes but which benefit hugely  
 from close
 power management and UI enhancements. Here we use Xorg (and even OpenGL) and
 measure RAM/storage in 100sMB/GBs.

I see no reason why OE + bitbake couldn't be used to build such  
images, except that work has already been done on the Debian build  
environment and that afair the support for building for and from  
Debian style files is still in its infancy.

I'm fully behind this project, I did a lot of work on and with the  
Zaurus and thoroughly enjoyed using OE + bitbake.

Cheers,


Simon



___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-24 Thread Carsten V. Munk
Kees Jongenburger wrote:
 Mer is an other excellent and
 but really different project with more focus on end-user usabilty v.s
 core reusability :p

   
Just to get any misconceptions out of the way - Mer actually does focus 
on core reusability, - we want Hildon and such to be portable, and 
preferably straight from upstream, so we don't have any deltas to them, 
- we have no interest in maintaining our own version of the Hildon 
platform, other than building it for the distribution.
You can see http://wiki.maemo.org/Mer/Documentation/Common_packages for 
our current status. Ideally we should have most packages being same 
version, or with only deltas for Mer specific functionality or 
compatibility.

We work on Mer not just to make Mer better, but to give the community a 
possibility to make valuable contributions to the Maemo platform and a 
place to experiment with new ideas, eventually easily adaptable to the 
consumer-targeted Maemo OS.

When Fremantle beta comes out we will submit patches to Hildon and Maemo 
software in order to improve portability (we have over 20+ weeks of work 
to contribute)  - such as removing Scratchbox-isms, assumptions on 
existence of packages because they're in Scratchbox devkit, and other 
things. This will improve the ability for anyone to take the Hildon 
packages straight from Maemo and use them in their build/packaging 
system, be it OE, Debian, Ubuntu, Gentoo, whereever.

I'm personally excited about the OpenEmbedded GSoC project, as it will 
help putting the Maemo platform on more devices and platforms where Mer 
for instance doesn't fit in so easily, and I'll do my part to help 
rkirti with her project - with the knowledge gained through burying 
ourselves deep in Maemo packages for over 20 weeks.

Stskeeps/Carsten V. Munk
Mer developer.

___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-24 Thread Stephen Gadsby
On Fri, Apr 24, 2009 at 1:47 PM, Carsten V. Munk c...@cs.au.dk wrote:
 You can see http://wiki.maemo.org/Mer/Documentation/Common_packages

There's a minor typo in this URL. It should be:
http://wiki.maemo.org/Mer/Documentation/Common_Packages

   -stephen
___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


Re: [GSoC 09] - Integrating Maemo in Open Embedded

2009-04-23 Thread Qole
I'm sure this is obvious, but I just want to be sure:

Please also look at the Mer project, since they are trying to build a Maemo
system, using only the open source pieces of Maemo. They are building their
system on Ubuntu, instead of OE, but their project might offer insight into
the problems you will encounter.

http://wiki.maemo.org/index.php?title=Mer

On Wed, Apr 22, 2009 at 3:33 AM, Kirtika Ruchandani kirt...@gmail.comwrote:

 Hello everyone,

 I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
 integrating Maemo in Open Embedded(OE) by creating a maemo image for the
 N800/N810 in OE.

 The project aim is to get a file-system image of maemo built in OE for the
 N800/N810 with all the Maemo software stack components - including the
 hildon UI environment. The work done for this will also include making the
 platform itself portable - i.e. being able to port Maemo components for a
 device over a given base, say angstrom.

 I will be looking at the Poky port of Maemo, previous work done by my
 mentor Florian Boor on this project, Mamona (which supports N800 in OE) and
 Angstrom (to be studied as a base) to go about the porting work.


 I am a second year under-graduate student at  Indian Institute of
 Technology, Madras (IIT-M) in India and my IRC and garage nickname is
 rkirti.




 --
 Kirtika Ruchandani
 Sophomore
 Computer Science and Engineering
 Indian Institute of Technology, Madras

 http://www.cse.iitm.ac.in/~rkirti/maemo-oe/http://www.cse.iitm.ac.in/%7Erkirti/maemo-oe/



 ___
 maemo-community mailing list
 maemo-community@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-community




-- 
enthusiast, n. One whose mind is wholly possessed and heated by what
engages it; one who is influenced by a peculiar fervor of mind; an ardent
and imaginative person.
___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community


[GSoC 09] - Integrating Maemo in Open Embedded

2009-04-22 Thread Kirtika Ruchandani
Hello everyone,

I am Kirtika Ruchandani, a Maemo-GSoC student this year working on
integrating Maemo in Open Embedded(OE) by creating a maemo image for the
N800/N810 in OE.

The project aim is to get a file-system image of maemo built in OE for the
N800/N810 with all the Maemo software stack components - including the
hildon UI environment. The work done for this will also include making the
platform itself portable - i.e. being able to port Maemo components for a
device over a given base, say angstrom.

I will be looking at the Poky port of Maemo, previous work done by my mentor
Florian Boor on this project, Mamona (which supports N800 in OE) and
Angstrom (to be studied as a base) to go about the porting work.


I am a second year under-graduate student at  Indian Institute of
Technology, Madras (IIT-M) in India and my IRC and garage nickname is
rkirti.




-- 
Kirtika Ruchandani
Sophomore
Computer Science and Engineering
Indian Institute of Technology, Madras

http://www.cse.iitm.ac.in/~rkirti/maemo-oe/
___
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community