Talk:SHR

From Openmoko

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.

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

Contents

some thoughts

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)

Package management

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)

Views

Personal tools

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.

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

some thoughts

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)

Package management

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)