(om-gta2 testing images available in neo1973 testing directory.)
(→Downloading images: Link to explanations of images.)
|Line 234:||Line 234:|
Currently, I'm stuck in trying to install SHR testing, because I do not know which images to use.<br>
Currently, I'm stuck in trying to install SHR testing, because I do not know which images to use.<br>
I noticed that om-gta2 testing files (including rootfs images) are available in the neo1973 directory at:<br>
I noticed that om-gta2 testing files (including rootfs images) are available in the neo1973 directory at:<br>
Revision as of 08:33, 13 January 2009
The freesmartphone framework daemons (ophoned, opreferencesd, odevicesd, etc...) have all been merged into a single daemon (frameworkd) So you will only need one package for all the freesmartphone functionalities. I am not sure yet of the stability of this daemon though.
Also, if you are looking for a set of applications using the framework, maybe you want to have a look at tichy (disclamer : this is my project) : http://charlie137-2.blogspot.com/2008/07/introducing-tichy.html
If you base your softwares on tichy, all you need to provide in you image is the freesmartphone framework, python, and a few standard python libraries.
--Charlie 11:43, 5 July 2008 (UTC)
A conversation between roh, wurp, paulproteus about how to get started on the project:
Jul 04 02:37:30 <paulproteus> wurp2|away, Cool, but I'd rather talk about the old-apps-on-FSO project. (-: Jul 04 02:37:53 <paulproteus> I wonder if we can easily package this for opkg. Jul 04 02:38:04 <wurp2|away> paulproteus: Sounds good. Sorry, I wsa reading the backlog. Jul 04 02:38:10 <paulproteus> No prob! Jul 04 02:39:06 <wurp2|away> I kept asking mickey why someone wasn't doing this (SHR) Jul 04 02:39:37 <paulproteus> His answer was, everyone else is too busy? Jul 04 02:39:44 <wurp2|away> And he said someone should, and pointed out that you could just build a phonekit-to-ophoned adapter, so finally today I got off my duff and started it Jul 04 02:40:02 <wurp2|away> Yeah, I knew he & his little group was too busy Jul 04 02:40:28 <wurp2|away> But I thought someone from OM could take the relatively small amount of time it *seems* like it should take Jul 04 02:40:29 * paulproteus nods and listens Jul 04 02:40:43 <wurp2|away> But, hey, if you want something done... Jul 04 02:41:17 <wurp2|away> So I'm not sure I have much more to say that isn't on the wiki Jul 04 02:41:30 <wurp2|away> IMO the first step is to get a good FSO image running from our repo Jul 04 02:41:33 <roh> hey guys Jul 04 02:41:39 <paulproteus> Hey now roh. Jul 04 02:41:42 * mwester hides Jul 04 02:42:01 <nezza-_-> hey roh Jul 04 02:42:05 <wurp2|away> Then build a phonekit stub that openmoko2-dialer (or whatever the name is) can pretend to connect to Jul 04 02:42:06 <paulproteus> wurp2|away, I agree - the first thing to do is just cone the current branch and have a repeatable build system. Jul 04 02:42:08 <wurp2|away> Hi roh Jul 04 02:42:11 <roh> about your project... i think youre overshooting the goal by soundling like 'we need to fork' Jul 04 02:42:29 <paulproteus> I see it more as a branch than a fork. But can you explain what you mean? Jul 04 02:42:32 <roh> but i see your goal and like it. Jul 04 02:42:45 <wurp2> roh: If we can get away without it, that would be great. I want to minimize what we're doing Jul 04 02:42:51 <paulproteus> Hopefully, as FSO people get interested in this, our branch would get rebased and disappears into FSO. Jul 04 02:42:59 <roh> eventually you should just do it where the main fun happens. in the repos we have. here is what i suggest: Jul 04 02:42:59 * mwester thinks the community needs commit rights, whatever you call it (fork or whatever) Jul 04 02:43:09 <wurp2> I fished around for suggestions of how we could go about just labelling, or just branching specific files, but got no feel-good answers Jul 04 02:43:18 * wurp2 listens. Jul 04 02:43:31 <roh> you start hacking and coding, and i will see that there is a milestone in trac, where you can organize tickets in Jul 04 02:43:48 <paulproteus> roh, in the fso trac? I'm sold. Jul 04 02:43:56 <roh> also about commit-rights.. thats quite easy. currently 2007.2 is basically unmaintained Jul 04 02:44:22 <paulproteus> So any development would really be the only branch, anyway? (-: Jul 04 02:44:23 <roh> paulproteus i dunno for sure. Jul 04 02:44:28 <paulproteus> Sure, but basically. Jul 04 02:45:41 <roh> the point is: we are currently thinking about reorganizing the buildprocess anyways.. so i would say we should a) see to get less distro-trees b) have a branch where the man with the hat for the branch commits stuff to. Jul 04 02:46:04 <wurp2> roh: Just to make sure I understand: are you suggesting we commit to the 2007.2 tree? Jul 04 02:46:14 <paulproteus> That's in svn, right? Jul 04 02:46:22 <wurp2> or I can just keep listening until you're done with your point :-) Jul 04 02:46:28 <roh> but the main point is: 2007.2 apps are in the main svn, but unmaintained. if somebody steps up and basically claims maintainership by doing real work i see not why we should hinder that. Jul 04 02:47:01 <roh> my only concern about that all is: i do not see reason for 'forking' or cluttering stuff even more than it currently is. Jul 04 02:47:17 <paulproteus> Okay, I can agree with that. Jul 04 02:47:25 * jeffszusz tries to make sense of the convo Jul 04 02:47:25 <roh> on the contrary, we need to get better oversight. and thats not what happens by using more different repos Jul 04 02:47:26 <wurp2> roh: Sounds great! Jul 04 02:47:42 <paulproteus> Now as far as build process, we'd still use the git OE repos and improve the bitbake files there? Jul 04 02:47:44 * mwester notes that he currently has a rather poor attitude about OM branches and commits, and steps out of the conversation. :( Jul 04 02:47:48 <nullpuppy> ok. finally home, now to try and put together a build environment ;) Jul 04 02:47:57 <paulproteus> We'd just make our own branch in that central OM git repo? Jul 04 02:47:57 <roh> i dunno for sure, but atm i think we do a daily build of gta01 and gta02 org.openmoko.dev Jul 04 02:48:06 <roh> the asu branch as well.. Jul 04 02:48:11 * jeffszusz didn't know there were forks/branches in OM Jul 04 02:48:13 <wurp2> So what do we do to get permission to check stuff into 2007.2? Jul 04 02:48:21 <roh> but i dunno who even uses these image (non-asu, old gtk based) or if they work at all. Jul 04 02:48:28 <paulproteus> Right. Jul 04 02:48:44 <alphabeat> dvarnes: http://wiki.openmoko.org/wiki/Group_Sales_Australia Jul 04 02:48:54 <wurp2> roh: They didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say Jul 04 02:49:03 <roh> wurp2 submit patches. i mean.. the recipe for the 2007.11 stuff should have a fixed svnrev, so even if you would break it it should even have the old states. Jul 04 02:49:08 <wurp2> s/They/2007.2/ Jul 04 02:49:09 <apt> wurp2 meant: roh: 2007.2 didn't work 3 weeks ago, then about 2 weeks ago someone said they (mostly) worked, but I dunno that they're maintained at all, as you say Jul 04 02:50:04 <roh> so i suggest: start hacking, start mailing patches.. i see that we clear up the repo as well as buildhost-situation. Jul 04 02:50:06 <dvarnes> alphabeat, yep .. already sent message to simon mathews with inquiry Jul 04 02:50:28 <wurp2> roh: OK, I'm very familiar with svn, and I have some experience with darcs and a knowledge of arch (RCSs like git) Jul 04 02:50:37 <wurp2> But I dunno how we would work off an svn tree Jul 04 02:50:41 <paulproteus> wurp2, IMHO we should use a git-svn repository to work on our patches then. Jul 04 02:50:42 <wurp2> and easily share changes with one another Jul 04 02:50:49 <paulproteus> That is quite feasible. Jul 04 02:50:56 <roh> its a 2-part story.. one part is basic distribution-building work (means should happen in a branch or head on git) Jul 04 02:50:59 <paulproteus> Another thing is to try quilt. Jul 04 02:51:00 <wurp2> then submit patches once we're happy to whoever to merge into main tree Jul 04 02:51:12 <paulproteus> I have to run in a minute, I'm very sorry to say! Jul 04 02:51:13 <roh> the other part is porting and changing applications, which should happen where the app lives. Jul 04 02:51:16 <wurp2> roh: Ah, I'm familiar with how to do it (basically) in git Jul 04 02:51:29 <paulproteus> roh, Yes, re: distribution work: would we get a branch in the main OM git then? Jul 04 02:51:35 <paulproteus> That would be fantastic. Jul 04 02:51:51 <paulproteus> And I *really* appreciate you stepping in here. Jul 04 02:51:56 <roh> i think that it would be the best way to do this. Jul 04 02:52:12 <alphabeat> dvarnes: might be a little late. i think he bought a few as overhead so you might be lucky :) we bought 60 but only needed 53 or something Jul 04 02:52:27 <wurp2> OK, I saw svn sneak in there for a bit, now we're talking about git again... which parts are git and which are svn? Jul 04 02:52:34 <paulproteus> svn for apps; git for OE work Jul 04 02:53:15 <wurp2> paulproteus: And you said quilt is a tool to help us share changes in our group, then create patches to submit to the main svn? Jul 04 02:53:15 <paulproteus> Email patches for apps, and get them in a state to use the FSO backend that way, sharing work between us before they're ready for submission using git-svn. Jul 04 02:53:16 <paulproteus> git for OE work - we'd get a branch in the OM git. Jul 04 02:53:16 <paulproteus> That's what I understand. Jul 04 02:53:26 <paulproteus> wurp2, Yes, quilt is an alternative to git-svn in this workflow. Jul 04 02:53:27 <Dave> We meet again, Mr. Wurp. Jul 04 02:53:38 <wurp2> wurp2: Ah, I think I prefer git-svn Jul 04 02:53:41 <paulproteus> I think so too. Jul 04 02:53:41 <wurp2> Dave: howdy Jul 04 02:53:52 <Dave> Howdy ya'll Jul 04 02:54:06 <wurp2> So we work in git, get it how we like it, then we create a patch Jul 04 02:54:14 <wurp2> keeping our git in sync w/ svn via git-svn Jul 04 02:54:25 <roh> wurp2 ? Jul 04 02:54:29 <wurp2> (er, and we submit the patch back to the svn owner, of course) Jul 04 02:54:29 <Dave> yep yep :) Jul 04 02:54:45 <wurp2> roh: Did I drift into crazy talk? Jul 04 02:55:04 <roh> i do not care how you branch/merge on your machine, but my point is that the app itself currently resides in svn.. and the distro which is 'one layer above' is in git Jul 04 02:55:10 * jeffszusz pulls out his cardboard Freerunner and pretends to talk on it Jul 04 02:55:26 <wurp2> roh: I think I understood that Jul 04 02:55:31 <Dave> Is this not self-evident enough from the repositories themselves? Jul 04 02:55:44 <Dave> jeffszusz: whoa, cool man, where can I get one? :D Jul 04 02:55:46 <roh> Dave since we have loads of them, sadly not all the time. Jul 04 02:55:53 <wurp2> roh: And dealing with the distro seems straightforward; we create a git repo that is a "child"(branch) of the main repo Jul 04 02:55:57 <Dave> Yeah, I noticed that too, roh :) Jul 04 02:56:04 <paulproteus> I have to run in 30-60s (-: Jul 04 02:56:04 <wurp2> and can submit changes back Jul 04 02:56:11 <wurp2> paulproteus: bye :-( Jul 04 02:56:15 <SpeedEvil> How long are confirmation emails taking to get sent out? Jul 04 02:56:19 <Dave> Even occasionally, and if it weren't for tagging, I'd mistake one for another frequently :) Jul 04 02:56:24 <jeffszusz> Dave: print, cut, paste! Jul 04 02:56:30 <paulproteus> wurp2, Right - we'll commit to a branch in OM git, and then we can ask the other branches to merge or cherry-pick our changes. Jul 04 02:56:33 <roh> also most projects are just about apps and not about 'lets build a device.. and while were at it write drivers for it.. ah.. and bootloaders.. and apps.-. and then package it in a linux-distri Jul 04 02:56:35 <SpeedEvil> Someone not had one after 3.5 hours. Is that overly delayed? Jul 04 02:56:47 <Dave> heh, true enough :) Jul 04 02:56:59 <wurp2> roh: But for apps, it seems that we need some way to share changes amongst ourselves w/o waiting for the patch to get accepted into the mainline, or even in some cases when we have things that aren't quite complete, that need another team member to finish Jul 04 02:56:59 <alphabeat> jeffzusz: did you print out the CAD file and make your own phone out of cardboard too? Jul 04 02:57:31 <roh> wurp2 for testing they could be applied in the distro dev branch. Jul 04 02:57:32 <jeffszusz> alphabeat: nope, but i'm tempted Jul 04 02:57:33 <dvarnes> alphabeat, yep .. understood .. I had looked a couple of times at the Group page, but the Aus one is not linked, so missed it. Not urgent since I already have a Neo :-) Still, am plannig to order a FR .. Jul 04 02:57:54 <Dave> Oh, I should write that report to the ml now. Jul 04 02:58:00 <wurp2> roh: So we were suggesting a SHR specific git repo, that would drift a bit from the app's svn until we get small changesets complete, then we would create patches Jul 04 02:58:05 <paulproteus> You guys, please store the results of this discussion on that wiki page. Jul 04 02:58:05 <paulproteus> Bye! Jul 04 02:58:13 <roh> i guess it would start with a -dev only branch.. if that then takes 'form' make it a stable one and branch the new --dev Jul 04 02:58:15 <wurp2> and keep our git repo in sync w/ the app repo via svn-git Jul 04 02:58:21 <roh> (the distro) Jul 04 02:58:43 <digitalslave> <would be happy just to get the emulator to compile blac Jul 04 02:58:44 * jeffszusz is realizing how little he knows about the progress of OpenMoko Jul 04 02:58:46 <wurp2> OK Jul 04 02:58:56 <roh> testing patches is in -dev as patch in oe.. then merge it into the repo (work with minrev and maxrev in the recipes) Jul 04 02:59:04 <wurp2> I'm hoping that our actual changes are fairly minimal Jul 04 02:59:48 <roh> i guess so. even then.. really.. nobody would want to hinder future maintainers of apps to evolve ;) Jul 04 02:59:57 <wurp2> A replacement for phonekit that delegates to ophoned, and a recipe to pull in compatible versions of all the basic apps Jul 04 02:59:59 <digitalslave> cd .. Jul 04 02:59:59 <digitalslave> ls Jul 04 03:00:06 <alphabeat> dvarnes: it looks like he ordered 60 with 52 phones confirmed and payed for and 6 phones unconfirmed which leaves 2 spare. might be lucky hey? ps jealous of buying a neo1973. should have got one :P Jul 04 03:00:13 <wurp2> digitalslave: Wrong window? Jul 04 03:00:27 <digitalslave> haha yep damn track pad heh Jul 04 03:00:48 <wurp2> digitalslave: At least it wasn't your root password Jul 04 03:01:06 <jeffszusz> wurp2: i did that before Jul 04 03:01:11 <digitalslave> hahaha Jul 04 03:01:21 <alphabeat> wurp2|jeffszusz: yah me too xD Jul 04 03:01:31 <wurp2> roh: I'll have to learn some more more before your -dev and --dev and minrev/maxrev stuff make sense to me :-) Jul 04 03:01:34 <digitalslave> i like reading all the logs at work from everyone putting there password in for their username :) Jul 04 03:01:38 <jeffszusz> i was due for a new password anyway... but i was lucky nobody used it before i had a chance to change it Jul 04 03:01:38 <jeffszusz> heh Jul 04 03:01:45 <wurp2> alphabeat, jeffszusz: :-( Jul 04 03:01:50 <alphabeat> digitalslave: you're evil! i like that Jul 04 03:02:11 <wurp2> It's also amazing what you'll see on a nic in promiscuous mode Jul 04 03:02:21 <digitalslave> haha true that! Jul 04 03:02:28 <roh> wurp2 in oe recipes one can define max, min or ranges thus of revisions which patches get applied. Jul 04 03:02:30 <wurp2> Like people's pwds on all the sites that didn't know enough to use https for login form submission Jul 04 03:03:04 <roh> wurp2 so if the patch which gets applied is merged, one sets the maxrev to one version below or so (atleast thats how i got it) Jul 04 03:03:14 <wurp2> roh: I see Jul 04 03:04:45 <wurp2> roh: How do we submit patches? openmoko-devel? Or is there a list of private email addys? Jul 04 03:05:08 <roh> yeah.. just the list Jul 04 03:05:16 <roh> or if you think it makes sense we Jul 04 03:05:31 <roh> eh we can add a milestone and you add them as attachment to tickets Jul 04 03:06:06 <wurp2> roh: That could work too... it seems like it would feel more reliable Jul 04 03:06:22 <wurp2> roh: As in, we can see a comment on the ticket that says submitted, and don't have to search email logs for it Jul 04 03:06:34 <roh> well.. its only how the 'group' of developers plans its workflow Jul 04 03:07:01 <wurp2> roh: Is there any material I can read to get some clues about this? Jul 04 03:07:19 <roh> eh.. which part Jul 04 03:07:31 <wurp2> Whichever parts have docs :-) Jul 04 03:07:43 <roh> ehehe Jul 04 03:08:01 <roh> well.. trac is easy.. it has documentation Jul 04 03:08:03 <wurp2> bitbake, how you're using milestones, what the procedure has been to submit patches in the past Jul 04 03:08:12 <wurp2> OK Jul 04 03:08:20 <wurp2> I've had "read up on trac" in my todo for a long time Jul 04 03:08:26 <wurp2> Now I guess I'll actually do it Jul 04 03:08:37 <roh> submitting patches... eh.. well..the opensource-default.. send by mail, do not mangle long lines ;) Jul 04 03:08:45 <roh> use diff -u eh svn diff -u Jul 04 03:09:09 <wurp2> Yeah, for that I was more concerned with internal procedures Jul 04 03:09:33 <wurp2> But I'm not even sure what the questoins are right now, so I'll just try it the way that seems obvious the first time Jul 04 03:09:34 <Dave> i.e. how the cabal performs its rituals ;) Jul 04 03:09:37 <wurp2> And get corrected Jul 04 03:09:44 <wurp2> Dave: exactly Jul 04 03:09:48 <wurp2> tribal knowledge Jul 04 03:09:52 <Dave> :) Jul 04 03:10:11 <Dave> Every tribe is different ;) Jul 04 03:10:23 <roh> wurp2 i think currently we are happy if people can code and submit good patches.. one easily looks over process minors then Jul 04 03:10:45 <Dave> That sounds encouraging. Jul 04 03:10:48 <wurp2> Well, I can code & submit patches Jul 04 03:10:58 <wurp2> We'll see if you conclude they are good or not ;-) Jul 04 03:11:27 <Dave> We'll see if you get voted off the island or not. ;) Jul 04 03:12:12 <wurp2> OK, 2007.2 is OM distro, right? Not apps, mostly? Jul 04 03:12:30 <wurp2> and 2007.2 is a git branch, yes? Jul 04 03:17:46 <roh> 2007.2 is a set of apps om did Jul 04 03:18:59 <wurp2> roh: OK
I was wondering what's the difference between this planned SHR and future release of FSO ? I mean, FSO is really great but lacks apps for the moment ; you're planning to port these apps from the GTK or the QT apps.
Why not contribute these ported applications to the FSO milestone 2 ?
I believe you should explain that in the page (or maybe I'm just confused by the description)
Jeremy List: Presuming this titchy thing is fairly lightweight in requirements it could be ideal for the main UI. However it needs a way of handling more items than will fit on the screen (for example, a scrollbar). and I would prefer using something with a different colour scheme.
- Jeremy : tichy already supports scrolling (I need to make it looks better and faster though), there is also a style system, that allow to dynamically modify not only the color scheme, but also the widgets sizes and look. Beside I modified the default look so that it is better by default. Check out the svn repository for a demonstration. It works fine even on desktop computer, without compiling. --Charlie 08:47, 21 July 2008 (UTC)
I wounder if it would be possible to replace openembeded with Debian, and include some key packages into the debian distribution such as illume, matchbox, the FSO framework, etc. (However that works.. a bunch of different dbus applications I imagine)
I believe the device has enough space to accomadate a full bash and apt-get and such, which would permit the ability to gain access to the huge armel debian package database and install ported software without the need to hassle yourself with bitbake files.
When we see the next generation of open palmtops come out with 64GB of internal flash, we will feel even more silly when we're using busybox and opkg.
Working parts of FSO
The section "Why not FSO?" of this article says: "FSO is by far the most stable & usable release, if all you want is a phone. (I mean *all*. It just has a dialer right now, not even call history.)". According to the Distributions page FSO has more features (and there are none listed for SHR). Which page is correct? Is this page outdated? --Marko Knöbl 22:39, 6 August 2008 (UTC)
http://build.shr-project.org/shr-testing/images/om-gta02/ contains two U-Boot images. Is there a difference between them? Clarifying this in the text would be useful. It confuses me that there are two U-Boot images.
I have tried to clarify that, but the root file system is missing in http://build.shr-project.org/shr-testing/images/om-gta02/ --Piratebab 17:49, 11 January 2009 (UTC)
Janvlug 10:05, 12 January 2009 (UTC) -- So, which root file system should I use when I want to use SHR testing?
Furthermore, it would be handy if somewhere was explained what the relation is between the files in the testing dir. For example that http://build.shr-project.org/shr-testing/images/om-gta02/uImage-2.6.24-oe3+gitrfb42ce6724576fc173faf8abfb04aa2c36d213b7-r1-om-gta02.bin and http://build.shr-project.org/shr-testing/images/om-gta02/uImage-om-gta02-latest.bin are the same.
What is the use of the modules file, should the files be copied over the (still to be gotten) root image files?
Currently, I'm stuck in trying to install SHR testing, because I do not know which images to use.
I noticed that om-gta2 testing files (including rootfs images) are available in the neo1973 directory at:
See this mail for more details about the images.