Re: [ALL] New showroom for Openmoko apps
On Mon, Aug 24, 2009 at 11:56:19PM +0100, Joao Pinto wrote: >I don't have a diagram for the APT-Portal database model, actually I >find more important the the rational used on it. It's pretty clear still :) Any pointers for the list on how to hack this thing? >On my perspective there are 3 key groups of information that you need >for a software portal: > >Back-End - Repository/Archive >This describes the organization of the software components and it's >relations on the archive, on my case there was nothing special to >define, APT has already a clear structure, there is a URL which points >to a repository , the repository is described by a "Release" file and >the contents of that repository/component is described at a Packages >file. >Because such repository is already defined as part of the distribution >system, I have just developed a script which imports data from a >generic APT repository to the database, the data on the repository >tables is populated from the "upstream" repository - there was an >exception introduced later, a package can either provide : m - main >package (provides an application). o - optional package (provides an >optional package for an application, like -server for a game) and i - >inter package (for data libraries etc), such classification is >directly related to packages and is not present on the repository, >this is the single human inpurt field introduced on this group. Ok, that's good to know, about the classification. Thanks :) After adding the user as an admin, there's a new link called Packages, which lets you edit these, and set the states for the packages. >Front-End - Application/Application Category >This provides the core information about an application, like >description, name, homage, description translations, screenshots, >youtube demos, etc. >There is no enforced reference (foreign key) to the repository group, >however there is a "source_package" field which identifies a source >package that (if available) provides the main and optional packages >for the application. Could/should this be a null foreign key? For some games at least source packages may be unavailable and thus the use case redundant for you, but for moko it would be really good to have streamlined support for sources. >Management - Who can do what >This provides the user and groups information, groups provide >privileges to manage both the repository and applications, so far we >are using a single group "admin" which can both defined/edit >application entries and issue repository management commands (remove, >copy from testing to stable) This is cool. >If you want to check the current tables definition just browse: >http://bazaar.launchpad.net/~apt-portal-devs/apt-portal/devel/files/head%3A/common/models/ > >Now talking about security, because that is specially key requirement >for any public site. > >General - apt-portal can easily be run using an appamor profile, >generic traversal, file retrieval/creation could be possible with code >exploits but are limited according to the strictness of the appamor >profile. Cool. >SQL Injection - we are using SQLAlchemy and bind parameters, sql >injection is not possible > >XSS Exploit - can be prevented by using Mako's templating engine >built-in html or url filtering on dynamic parts on the templates Yeah, these two belong in the nineties. >Please give a try to APT-Portal, I do not know if it can cover your >requirements, if it does it would be a great collaboration >opportunity, working on the back-end requires specific knowledge on >repository the technology used, bout the front-end and management >could easily be shared across different projects. We need to discuss about source packages at least, and how to do different distributions, and probably code layout where all the paths live (I haven't really done cherrypy before ;) Anyway, I've seen worse starts than this, I say we proceed from here :) Obrigado! -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Tue, Aug 25, 2009 at 09:21:37PM +0300, Risto H. Kurppa wrote: >Someone please test apt-portal and see what it offers or how much work >it is to hack it to do what we want. I installed it as Joao Pinto suggested, like http://wiki.getdeb.net/apt-portal/Download and it worked without a problem. Anyone else care to try too? >I don't think it's much work: >oe-based distros and debian shouldn't be a problem since the >repositories are veeery close to the ubuntu repositories used by >playdeb -> I'd guess that setting up the first versions is a breeze >(for someone who knows python & web-things..). I for one have never used these technologies, but a tutorial should kick me along nicely ;) Anyone else care to try too? >- Packages classification (main, optional, additional) >- Translation support for the site template Should be easy enough. >- List recent changes to the repository (with apturl feeds) Any pointers on how this should work? >- Support for packages/applications descriptions translation Probably ok. >- Automated packages information import/update from Packages(.gz,/.bz2) files > -> works out of the box for oe-based and debian based distros?! Post-dput hook or something? At the very least a cronjob? >- AJAX filter/search for names, descriptions and tags > -> tags can be used to separate different distro releases? Myeah whatever apt-portal gives us and then see if we need something more.. >As playdeb already supports different Ubuntu version (like 9.04, 8.10 >etc..) I can't image it being hard to change apt-portal to manage >these as different distros (om2009, SHR, debian..) see >http://www.playdeb.net/release_select/ Maybe yes, maybe no. Ubuntus and Debians (I'm half on memory here, correct me if I'm wrong) can share a pool directory and have the dists directory tell us which version of which package belongs to which distro. So for this to work with apt-portal om2009, shr and debian would have to be identical enough to work as only ubuntu or only debian, by having everything in one place and having the Packages file filter them to the correct distros. The bottom line, then, looks a bit like we need to figure out how to manage the repository/repositories that apt-portal shows to the community, right? >Building from scratch is tons of work and stupid as we already have >apt-portal around. +1024 >And app-centric vs. distro-centric, I don't think it makes sense to >create separate installations of apt-portal for each distro but have >all apps in the same system separating distros by >tags/categories/source repositories. So the first thing a user selects >is his distro and then he'd only see the apps for his distro. Myeah, but I think the comments should be in some context of the distro, like I said elsewhere, because of eg. vendor drift and vastly different versions. "I really liked the game but it sucked how it wasn't completable **" - SHR "Great game, especially now that it's completable *" - Om ;P Anyway, let's feel around apt-portal for a while and see what it can do for us.. >-> my 2 cents go for apt-portal so now we have.. hmm.. not enought to >buzz-fix FR of the one who sets up apt-portal for us :) Anything production-grade will take a long while :P -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Someone please test apt-portal and see what it offers or how much work it is to hack it to do what we want. I don't think it's much work: oe-based distros and debian shouldn't be a problem since the repositories are veeery close to the ubuntu repositories used by playdeb -> I'd guess that setting up the first versions is a breeze (for someone who knows python & web-things..). - Packages classification (main, optional, additional) - Translation support for the site template - List recent changes to the repository (with apturl feeds) - Support for packages/applications descriptions translation - Automated packages information import/update from Packages(.gz,/.bz2) files -> works out of the box for oe-based and debian based distros?! - AJAX filter/search for names, descriptions and tags -> tags can be used to separate different distro releases? As playdeb already supports different Ubuntu version (like 9.04, 8.10 etc..) I can't image it being hard to change apt-portal to manage these as different distros (om2009, SHR, debian..) see http://www.playdeb.net/release_select/ Building from scratch is tons of work and stupid as we already have apt-portal around. And app-centric vs. distro-centric, I don't think it makes sense to create separate installations of apt-portal for each distro but have all apps in the same system separating distros by tags/categories/source repositories. So the first thing a user selects is his distro and then he'd only see the apps for his distro. -> my 2 cents go for apt-portal so now we have.. hmm.. not enought to buzz-fix FR of the one who sets up apt-portal for us :) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
My opinion is that building a tool like this ourselves is definitely the last resort - we have limited resources for the FR - let's not spend them re-inventing the wheel. I'm not so sure about seperating out comments and information based on the distribution / app version / etc... would it be possible to put everything in one app-centric place, but tag the comments etc. with version/distro/etc? One use case that I think is very valuable it be able to see what everyone else is saying about an app - for instance does MyMailApp work well with IMAP - that's not generally going to be tied to a specific distro, and not necessarily to a specific version. If I have to go through a bunch of different pages to see all the comments people have added about MyMailApp, it'd be quite annoying. Of course, another question is does MyMailApp 0.93 work on SHR-Unstable built on Aug 15th - for that you'd like to be able to filter comments by distro and app-version... On Tue, Aug 25, 2009 at 12:09 PM, Sebastian Krzyszkowiak < seba.d...@gmail.com> wrote: > On 8/25/09, David Reyes Samblas Martinez wrote: > >> Well, app-oriented showroom will be easier to maintain (well, i'm not > >> sure about that), but less useful for users and applications using > >> data from that showroom (about that i'm sure :P). > > Ok so this argument has conviced me about a separate showroom by > > distro, one of the goals is that the info can be reused, so if in this > > way can be easier lets take this approach > >> > >> Also, I would love to see self-built packages abbandoned at all and > >> not used in such showroom, as they only produce mess and problems. > > Distro mantainers have to work towards including this apps on their > > distros to not let scape any of those cool apps (duke3d, doom, are an > > example of cool apps lost in the distro evolutions) > > Can't agree more. Application developers just have to provide distro > friendly sources (preferrably git or svn repo, but tarball hosted on > trusted server is also ok), packaging and integrating into distro has > to be done by distro developers. This way packages won't be out of > date and data in showroom will be really easier to maintain. > > -- > Sebastian Krzyszkowiak > dos > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/25/09, David Reyes Samblas Martinez wrote: >> Well, app-oriented showroom will be easier to maintain (well, i'm not >> sure about that), but less useful for users and applications using >> data from that showroom (about that i'm sure :P). > Ok so this argument has conviced me about a separate showroom by > distro, one of the goals is that the info can be reused, so if in this > way can be easier lets take this approach >> >> Also, I would love to see self-built packages abbandoned at all and >> not used in such showroom, as they only produce mess and problems. > Distro mantainers have to work towards including this apps on their > distros to not let scape any of those cool apps (duke3d, doom, are an > example of cool apps lost in the distro evolutions) Can't agree more. Application developers just have to provide distro friendly sources (preferrably git or svn repo, but tarball hosted on trusted server is also ok), packaging and integrating into distro has to be done by distro developers. This way packages won't be out of date and data in showroom will be really easier to maintain. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> Well, app-oriented showroom will be easier to maintain (well, i'm not > sure about that), but less useful for users and applications using > data from that showroom (about that i'm sure :P). Ok so this argument has conviced me about a separate showroom by distro, one of the goals is that the info can be reused, so if in this way can be easier lets take this approach > > Also, I would love to see self-built packages abbandoned at all and > not used in such showroom, as they only produce mess and problems. Distro mantainers have to work towards including this apps on their distros to not let scape any of those cool apps (duke3d, doom, are an example of cool apps lost in the distro evolutions) > > -- > Sebastian Krzyszkowiak > dos > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> I still have to test apt-portal and I encourage others to do that too, > because if it delivers 99% of what we need, then I suggest we go with > whatever it offers and build on that. +1 > Knowing from experience that building these things from scratch is > a lot of work... +1000 > > -- > mjt > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/25/09, David Reyes Samblas Martinez wrote: > >> How should different distributions be combined in the showroom? >> -> >> This is difficult since package information from different repositories >> is is likely to differ. That means for example: should we use the >> description provided by SHR or the one from Gentoo? >> My first thought was, to just use information from SHR and if the same >> application is available in a different distro add something like "Also >> available for Gentoo". This is flawed however because maybe a package >> provided by Gentoo isn't available in SHR and just putting it into "not >> categorized" feels wrong. >> So im my opinion there should be a showroom for each distribution. This >> way it is easy to display distribution specific information on an >> application. > I a little disagree with you here, I like the vision of the apt-get > portal to be aplication-centric instead of distro-centric, I agree to > extract info form the repos , and this info will be useful to > initialize the bd, etc but the users will have the availability to > enrich this descriptions and adding pics and vids, comments, voting, > karma and whatever fancy thing we want/can include and all this will > be managed by the showroom it self, > an application will have some characteristics and those can be > perfectly in what distro/machine/version is included and the level of > working state but is assumed than if is included in a distro will have > some level of usable state >> >> Isn't it very inefficient to have several showrooms (one per >> distribution)? >> -> >> Not neccessarily. Completely unrelated showrooms would of course result >> in additional work. For example one would upload similar or even the >> same screenshots several times for different distributions. >> A good solution would be to relate these showrooms together. That means >> to have a kind of "masterlist" were all applications from all >> distributions are collected. Screenshots and comments aren't attached >> to an application in a single showroom, but to the name of the >> application on the "masterlist". >> When viewing an application on the SHR-showroom displayed information >> comes from bb-files, but screenshots and comments come from the >> "masterlist". If viewing the same application on the Gentoo-showroom >> the same screenshots and comments would be showed, but the application >> information and category may differ. > As said before I prefer only one distro agnostic showroom, much more > easy to mantain , and if some one only wants to navigate trough only > one distro apps, use a filter. >> >> Maybe comments should be tagged so one can toggle between "Show all" >> and "Show distribution specific". > Good point >> >> >> Do we want to support more hardware than the Freerunner? >> -> >> Definitely yes, or have you forgotten about the neo-gta01 pioneers? >> And in case someday gta03/gta02core really materializes it >> deserves a place in the showroom, too. However I still have to think >> more about supporting multiple hardware. Maybe someone else with good >> thoughts on this? > Just another field on the characteristics of the app to be filled. >> >> Please excuse my shiftless examples including SHR and Gentoo only, >> other distris are great, too ;) > Your are welcome ;) >> >> jxs >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > Well, app-oriented showroom will be easier to maintain (well, i'm not sure about that), but less useful for users and applications using data from that showroom (about that i'm sure :P). Also, I would love to see self-built packages abbandoned at all and not used in such showroom, as they only produce mess and problems. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Tue, Aug 25, 2009 at 03:36:16PM +0200, David Reyes Samblas Martinez wrote: >I a little disagree with you here, I like the vision of the apt-get >portal to be aplication-centric instead of distro-centric, I agree to >extract info form the repos , and this info will be useful to >initialize the bd, etc but the users will have the availability to >enrich this descriptions and adding pics and vids, comments, voting, >karma and whatever fancy thing we want/can include and all this will >be managed by the showroom it self, >an application will have some characteristics and those can be >perfectly in what distro/machine/version is included and the level of >working state but is assumed than if is included in a distro will have >some level of usable state It can't really be app-centric because apps have versions, major and minor, and distributions (can) have "vendor patches" and whatever. It's simply not fair to anyone to have app-centric comments, they need to be in context. >> Isn't it very inefficient to have several showrooms (one per >> distribution)? >> -> >> Not neccessarily. Completely unrelated showrooms would of course result >> in additional work. For example one would upload similar or even the >> same screenshots several times for different distributions. >> A good solution would be to relate these showrooms together. That means >> to have a kind of "masterlist" were all applications from all >> distributions are collected. Screenshots and comments aren't attached >> to an application in a single showroom, but to the name of the >> application on the "masterlist". >> When viewing an application on the SHR-showroom displayed information >> comes from bb-files, but screenshots and comments come from the >> "masterlist". If viewing the same application on the Gentoo-showroom >> the same screenshots and comments would be showed, but the application >> information and category may differ. >As said before I prefer only one distro agnostic showroom, much more >easy to mantain , and if some one only wants to navigate trough only >one distro apps, use a filter. I still have to test apt-portal and I encourage others to do that too, because if it delivers 99% of what we need, then I suggest we go with whatever it offers and build on that. Knowing from experience that building these things from scratch is a lot of work... -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > Do we want to support more hardware than the Freerunner? IMHO - no. If this hardware supports some distro, than application would run on it. Opposite example would be showroom for distributions, where you should tell if some distro runs on particular hardware. [cut] -- Kind Regards, Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > I a little disagree with you here, I like the vision of the apt-get > portal to be aplication-centric instead of distro-centric, I agree to Each distro has it's own bb files. How do you imagine concatenating these? Several app's descriptions from each distro? You have to divide showroom into distros to separate their bb files. [cut] -- Kind Regards, Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> How should different distributions be combined in the showroom? > -> > This is difficult since package information from different repositories > is is likely to differ. That means for example: should we use the > description provided by SHR or the one from Gentoo? > My first thought was, to just use information from SHR and if the same > application is available in a different distro add something like "Also > available for Gentoo". This is flawed however because maybe a package > provided by Gentoo isn't available in SHR and just putting it into "not > categorized" feels wrong. > So im my opinion there should be a showroom for each distribution. This > way it is easy to display distribution specific information on an > application. I a little disagree with you here, I like the vision of the apt-get portal to be aplication-centric instead of distro-centric, I agree to extract info form the repos , and this info will be useful to initialize the bd, etc but the users will have the availability to enrich this descriptions and adding pics and vids, comments, voting, karma and whatever fancy thing we want/can include and all this will be managed by the showroom it self, an application will have some characteristics and those can be perfectly in what distro/machine/version is included and the level of working state but is assumed than if is included in a distro will have some level of usable state > > Isn't it very inefficient to have several showrooms (one per > distribution)? > -> > Not neccessarily. Completely unrelated showrooms would of course result > in additional work. For example one would upload similar or even the > same screenshots several times for different distributions. > A good solution would be to relate these showrooms together. That means > to have a kind of "masterlist" were all applications from all > distributions are collected. Screenshots and comments aren't attached > to an application in a single showroom, but to the name of the > application on the "masterlist". > When viewing an application on the SHR-showroom displayed information > comes from bb-files, but screenshots and comments come from the > "masterlist". If viewing the same application on the Gentoo-showroom > the same screenshots and comments would be showed, but the application > information and category may differ. As said before I prefer only one distro agnostic showroom, much more easy to mantain , and if some one only wants to navigate trough only one distro apps, use a filter. > > Maybe comments should be tagged so one can toggle between "Show all" > and "Show distribution specific". Good point > > > Do we want to support more hardware than the Freerunner? > -> > Definitely yes, or have you forgotten about the neo-gta01 pioneers? > And in case someday gta03/gta02core really materializes it > deserves a place in the showroom, too. However I still have to think > more about supporting multiple hardware. Maybe someone else with good > thoughts on this? Just another field on the characteristics of the app to be filled. > > Please excuse my shiftless examples including SHR and Gentoo only, > other distris are great, too ;) Your are welcome ;) > > jxs > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
I have spend several hours thinking about how a good application showroom should look like. Here are some questions I asked myself: Should the showroom be filled automatically from a repository? -> YES, we can spend our time better than adding applications and updating broken ones manually. Distribution maintainers already take care of this. As proposed by David Reyes Samblas information could be extracted from bb-files (btw how can one retrieve the bb-files?). Categorization could be done via .desktop-files. Do we need Screenshots, Comments, Ratings etc? -> YES, it should be possible to add screenshots to the automatically created apps in the showroom or to comment on them. Should the showroom be SHR/Openembedded only? -> NO, it should include applications for as many distributions as possible. Lets assume we want to have SHR and Gentoo in the showroom (we would have to find a way to automatically extract applications available on Gentoo). How should different distributions be combined in the showroom? -> This is difficult since package information from different repositories is is likely to differ. That means for example: should we use the description provided by SHR or the one from Gentoo? My first thought was, to just use information from SHR and if the same application is available in a different distro add something like "Also available for Gentoo". This is flawed however because maybe a package provided by Gentoo isn't available in SHR and just putting it into "not categorized" feels wrong. So im my opinion there should be a showroom for each distribution. This way it is easy to display distribution specific information on an application. Isn't it very inefficient to have several showrooms (one per distribution)? -> Not neccessarily. Completely unrelated showrooms would of course result in additional work. For example one would upload similar or even the same screenshots several times for different distributions. A good solution would be to relate these showrooms together. That means to have a kind of "masterlist" were all applications from all distributions are collected. Screenshots and comments aren't attached to an application in a single showroom, but to the name of the application on the "masterlist". When viewing an application on the SHR-showroom displayed information comes from bb-files, but screenshots and comments come from the "masterlist". If viewing the same application on the Gentoo-showroom the same screenshots and comments would be showed, but the application information and category may differ. Maybe comments should be tagged so one can toggle between "Show all" and "Show distribution specific". Do we want to support more hardware than the Freerunner? -> Definitely yes, or have you forgotten about the neo-gta01 pioneers? And in case someday gta03/gta02core really materializes it deserves a place in the showroom, too. However I still have to think more about supporting multiple hardware. Maybe someone else with good thoughts on this? Please excuse my shiftless examples including SHR and Gentoo only, other distris are great, too ;) jxs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> But as RHK pointed out in the next email, someone should test apt-portal, > because that was talked about earlier and it already exists and should > be good enough and I've exchanged words with Joao Pinto about it.. > > ... Which makes me at least one prime candidate to test it, but today was > a horrible Monday. > > David Martinez of Tuxbrain dabbled in it, wonder if anything came out of it? > > I'll give it a shot tomorrow. > > -- > mjt > Hello, I don't have a diagram for the APT-Portal database model, actually I find more important the the rational used on it. When I have developed the database design for www.getdeb.net 3 years ago, I had a great focus on data, on it's representation as entities (tables) and relations. It has been usable, however I have found myself building complex queries and code to achieve simple goals. This time I have followed the opposite direction and so far I am happy with the results. On my perspective there are 3 key groups of information that you need for a software portal: Back-End - Repository/Archive This describes the organization of the software components and it's relations on the archive, on my case there was nothing special to define, APT has already a clear structure, there is a URL which points to a repository , the repository is described by a "Release" file and the contents of that repository/component is described at a Packages file. Because such repository is already defined as part of the distribution system, I have just developed a script which imports data from a generic APT repository to the database, the data on the repository tables is populated from the "upstream" repository - there was an exception introduced later, a package can either provide : m - main package (provides an application). o - optional package (provides an optional package for an application, like -server for a game) and i - inter package (for data libraries etc), such classification is directly related to packages and is not present on the repository, this is the single human inpurt field introduced on this group. Front-End - Application/Application Category This provides the core information about an application, like description, name, homage, description translations, screenshots, youtube demos, etc. There is no enforced reference (foreign key) to the repository group, however there is a "source_package" field which identifies a source package that (if available) provides the main and optional packages for the application. Management - Who can do what This provides the user and groups information, groups provide privileges to manage both the repository and applications, so far we are using a single group "admin" which can both defined/edit application entries and issue repository management commands (remove, copy from testing to stable) If you want to check the current tables definition just browse: http://bazaar.launchpad.net/~apt-portal-devs/apt-portal/devel/files/head%3A/common/models/ Now talking about security, because that is specially key requirement for any public site. General - apt-portal can easily be run using an appamor profile, generic traversal, file retrieval/creation could be possible with code exploits but are limited according to the strictness of the appamor profile. SQL Injection - we are using SQLAlchemy and bind parameters, sql injection is not possible XSS Exploit - can be prevented by using Mako's templating engine built-in html or url filtering on dynamic parts on the templates Please give a try to APT-Portal, I do not know if it can cover your requirements, if it does it would be a great collaboration opportunity, working on the back-end requires specific knowledge on repository the technology used, bout the front-end and management could easily be shared across different projects. If you have an Ubuntu LiveCD around just test-drive http://www.playdeb.net/, it's built on top of APT-Portal . Thanks -- João LuÃs Marques Pinto GetDeb Team Leader http://www.getdeb.net http://blog.getdeb.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/24 Risto H. Kurppa : > So anyone had any success in trying out apt-portal ( > http://wiki.getdeb.net/apt-portal/Download ) > > joaopinto at #getdeb is willing to help anyone running into problems. > Hi Risto not success yet, the thread problem persist and I have checked that the cherrypy3 pkg is the one of page not the jaunty one. Next step is to test it on a debian-testing system and if succed try it on a debian Lenny used in openmoko.org,why on testing first? Because there's a lot time passed since I played with debian the last time and testing includes a 2.6.30 Kernel(yes just personal reasons and curiosity) the main issue is that booth debian system not have python2.6 in their standard repos it's only abiablen on debian experimental so let's see how all this will finish. I also notice in this thread are two clear tendences one is use somethng already done and adapt it (apt-portal) and the other is write something from scratch (UML diag, object defiition etc...), I would like to dedicate my few and scare efforts to the winning horse so what do you(all) think are the best approach? > r > > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Mon, Aug 24, 2009 at 11:00:13AM -0500, Cristian Gómez wrote: > >I think mosts of your suggestions make perfect sense, I'll update the >diagram as soon as I can. But reading your comments I think that maybe we >should make a DB diagram instead to make things clearly from the DB >perspective and then we should update the Classes diagram, what do you >think? I was reading those more or less as DB tables, so I based my feedback on that. But as RHK pointed out in the next email, someone should test apt-portal, because that was talked about earlier and it already exists and should be good enough and I've exchanged words with Joao Pinto about it.. ... Which makes me at least one prime candidate to test it, but today was a horrible Monday. David Martinez of Tuxbrain dabbled in it, wonder if anything came out of it? I'll give it a shot tomorrow. -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
So anyone had any success in trying out apt-portal ( http://wiki.getdeb.net/apt-portal/Download ) joaopinto at #getdeb is willing to help anyone running into problems. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Sunder, Markus thank you so much for the feedback. Here's what I think - About the cardinality, I don't use it too much in class diagram but I will include cardinality in the diagram to make it clear - I have doubts about the versions of a application. I think that versions (Release class as you point) have many in common attributes with the Application itself (each version can have different author(s), downloadURL, installation instructions, etc). Maybe in the Application class we only need to store the app name, description and in the versions, the authors, downloadURL, etc. - User karma is like popularity for application, I think that we may implement a way to say thanks to developers/maintainers by given them karma points. Same way as we will have a Top 10 applications, we should have Top 10 contributors IMHO. I think mosts of your suggestions make perfect sense, I'll update the diagram as soon as I can. But reading your comments I think that maybe we should make a DB diagram instead to make things clearly from the DB perspective and then we should update the Classes diagram, what do you think? /*** * Don't Worry...Be Linux * Cristian Gómez Alvarez * Ingeniero en Sistemas y Computación * Universidad de Caldas * Comunidad de Software Libre Manizales * IEEE/WIE Student Member * Linux User #463617 * Mi Blog: http://cristianpark.sehablalinux.com/ / 2009/8/23 Sander van Grieken > On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote: > > Hi all, I were following this thread and I think that the most remarkable > > post is this one from Martin who resumes the most important things that > we > > want to have in the showroom page. > > > > I made this Classes diagram [1] in DIA to make the basis for the > > development of the site. It's really basic but I think that it's a start > > point. > > I'm missing the cardinality and direction in the relations. Second, you > should add a > Release class (one-to-many) to distinguish versions of applications. Also > abstract the > File class to a Resource class (You can then subclass File from Resource to > specialize), > this allows you flexibility in the resource type (which could be a > screenshot, like you > modeled, but also for example a howto, FAQ, homepage whatever). > > Application has no 'belongs to' relationship to Distribution. Instead, > Distribution has a > 'provides' relationship to Application. The Application attribute > 'multiplatform' is > useless. 'provedOn', 'notWorkingOn', 'distribution' are all one-to-many > associations and > should be modeled in the diagram. 'author' should be a list or even an > association, not a > string. > > popularity is a derived attribute (pun intended) > > grtz, > Sander > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Sun, Aug 23, 2009 at 02:36:44AM -0500, Cristian Gómez wrote: >I made this Classes diagram [1] in DIA to make the basis for the development >of the site. It's really basic but I think that it's a start point. I put my two cents in another message but I'll put some cents here too :) >I'll explain several points to make the diagram clear: >* The classes have the attributes that I can figure out from the requests on >this thread. Sure, whatever. >* A user can be a maintainer of a distribution/application or just a regular >user (someone with account in the page who can vote for the distros/apps >popularity) I like it; a user is a user, the attributes are attributes. >* The "File" class (table) contains the files (commonly image files) of the >three entities: distros/apps (screenshots); user (user image) >* The distros and the apps have an attribute to represent their popularity >(a float number from 1 to 5) that is set with a stored procedure that update >the "popularity" field with the average of the califications of the users >for the distro/application (a user only can vote once for an distro/app, >which makes the popularity more reliable). The procedure is triggered >whenever an user give a distro/app application) Denormalization techniques are better for sites that take a lot of hits and don't want to calculate aggregates on every request, because they are read much more than written to. I think the moko application db will never be popular enough to benefit from this, and having stored procs can clutter the code. >TODO>I don't know if the diagram is usable/compatible with the apt-portal idea >but is my way to bring my two cents for the cause.. I haven't had time to look at apt-portal yet, and I don't know if anyone yet has, but we'll see.. :) Thanks! -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Mon, Aug 24, 2009 at 01:07:07AM +0200, Sander van Grieken wrote: >On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote: First off, thanks to Cristian for making this, clearly it has been a good starting point for us, because there have been suggestions for improvement! :) >I'm missing the cardinality and direction in the relations. Second, you >should add a Release class (one-to-many) to distinguish versions of >applications. Also abstract the File class to a Resource class (You can then >subclass File from Resource to specialize), this allows you flexibility in >the resource type (which could be a screenshot, like you modeled, but also >for example a howto, FAQ, homepage whatever). The directions are IMO quite clear anyway, but I have to agree with the Release table. Also distribution needs to drop author, authorEmail, installationInstructions and downloadURL and most of the other stuff. Author stuff can be in a distribution_maintainers table, which would glue distributions and users together. lastReleaseDate and stuff would come from the Release table. >Application has no 'belongs to' relationship to Distribution. Instead, >Distribution has a 'provides' relationship to Application. This is UML arrowtech? that the arrows are wrong? (I actually wrote in a job application that I know "Whiteboard UML" because it's just easier to draw lines and arrows and explain only where it's not self-evident ;) >The Application >attribute 'multiplatform' is useless. 'provedOn', 'notWorkingOn', >'distribution' are all one-to-many associations and should be modeled in the >diagram. 'author' should be a list or even an association, not a >string. Amen. >popularity is a derived attribute (pun intended) And user karma is not explained and studdlyCaps look like stupidCraps. -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Sunday 23 August 2009 09:36:44 Cristian Gómez wrote: > Hi all, I were following this thread and I think that the most remarkable > post is this one from Martin who resumes the most important things that we > want to have in the showroom page. > > I made this Classes diagram [1] in DIA to make the basis for the > development of the site. It's really basic but I think that it's a start > point. I'm missing the cardinality and direction in the relations. Second, you should add a Release class (one-to-many) to distinguish versions of applications. Also abstract the File class to a Resource class (You can then subclass File from Resource to specialize), this allows you flexibility in the resource type (which could be a screenshot, like you modeled, but also for example a howto, FAQ, homepage whatever). Application has no 'belongs to' relationship to Distribution. Instead, Distribution has a 'provides' relationship to Application. The Application attribute 'multiplatform' is useless. 'provedOn', 'notWorkingOn', 'distribution' are all one-to-many associations and should be modeled in the diagram. 'author' should be a list or even an association, not a string. popularity is a derived attribute (pun intended) grtz, Sander ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
u you're right Risto, I just forgot to tell that I exported the diagram to png and is available in the .tar.gz that I upload. /*** * Don't Worry...Be Linux * Cristian Gómez Alvarez * Ingeniero en Sistemas y Computación * Universidad de Caldas * Comunidad de Software Libre Manizales * IEEE/WIE Student Member * Linux User #463617 * Mi Blog: http://cristianpark.sehablalinux.com/ / 2009/8/23 Risto H. Kurppa > 2009/8/23 Cristian Gómez : > > Hi all, I were following this thread and I think that the most remarkable > > post is this one from Martin who resumes the most important things that > we > > want to have in the showroom page. > > > > I made this Classes diagram [1] in DIA to make the basis for the > development > > of the site. It's really basic but I think that it's a start point. > > Wow, thanks for this! I'll try to have a look at it later, don't have > DIA around now.. (an png would be nice and readable for everyone :) > > Maybe someone else can have a look and comment > > r > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/23 Cristian Gómez : > Hi all, I were following this thread and I think that the most remarkable > post is this one from Martin who resumes the most important things that we > want to have in the showroom page. > > I made this Classes diagram [1] in DIA to make the basis for the development > of the site. It's really basic but I think that it's a start point. Wow, thanks for this! I'll try to have a look at it later, don't have DIA around now.. (an png would be nice and readable for everyone :) Maybe someone else can have a look and comment r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/23/09, Marcel wrote: > Am Sonntag, den 23.08.2009, 11:29 +0200 schrieb Laszlo KREKACS: >> On Fri, Aug 21, 2009 at 10:49 AM, Sebastian >> Krzyszkowiak wrote: >> > It was discussed DOZENS of times on maillist. Sending bb recipe (or >> > asking for writing such recipe) to shr-devel maillist is in majority >> > enough to have your app in SHR and FSO repositiories, which is enough, >> > as I don't know other active and supported OpenEmbedded based distro >> > here which isn't based on SHR or Om2009. >> >> >> I would love to see paroli installable into shr > > Me too! a) that's not topic for that b) i just saw Ainulindale working on getting newest Paroli into SHR There already was Paroli in SHR, but in really old version. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Am Sonntag, den 23.08.2009, 11:29 +0200 schrieb Laszlo KREKACS: > On Fri, Aug 21, 2009 at 10:49 AM, Sebastian > Krzyszkowiak wrote: > > It was discussed DOZENS of times on maillist. Sending bb recipe (or > > asking for writing such recipe) to shr-devel maillist is in majority > > enough to have your app in SHR and FSO repositiories, which is enough, > > as I don't know other active and supported OpenEmbedded based distro > > here which isn't based on SHR or Om2009. > > > I would love to see paroli installable into shr Me too! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 10:49 AM, Sebastian Krzyszkowiak wrote: > It was discussed DOZENS of times on maillist. Sending bb recipe (or > asking for writing such recipe) to shr-devel maillist is in majority > enough to have your app in SHR and FSO repositiories, which is enough, > as I don't know other active and supported OpenEmbedded based distro > here which isn't based on SHR or Om2009. I would love to see paroli installable into shr Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Hi all, I were following this thread and I think that the most remarkable post is this one from Martin who resumes the most important things that we want to have in the showroom page. I made this Classes diagram [1] in DIA to make the basis for the development of the site. It's really basic but I think that it's a start point. I'll explain several points to make the diagram clear: * The classes have the attributes that I can figure out from the requests on this thread. * A user can be a maintainer of a distribution/application or just a regular user (someone with account in the page who can vote for the distros/apps popularity) * The "File" class (table) contains the files (commonly image files) of the three entities: distros/apps (screenshots); user (user image) * The distros and the apps have an attribute to represent their popularity (a float number from 1 to 5) that is set with a stored procedure that update the "popularity" field with the average of the califications of the users for the distro/application (a user only can vote once for an distro/app, which makes the popularity more reliable). The procedure is triggered whenever an user give a distro/app application) TODO: * Discuss if any registered user can edit the information of a distro/app or how it will be covered. * Reppresent the dependencies of an application * Other things that you want Note: DIA diagram contains attribute description for each class I don't know if the diagram is usable/compatible with the apt-portal idea but is my way to bring my two cents for the cause.. Remember that you're welcome to make adjustments to the diagram in order to make it more representative of the situation of a AppDB for the FR. Greetings from Colombia [1] http://www.mediafire.com/download.php?kyyzzcuz3kt /*** * Don't Worry...Be Linux * Cristian Gómez Alvarez * Ingeniero en Sistemas y Computación * Universidad de Caldas * Comunidad de Software Libre Manizales * IEEE/WIE Student Member * Linux User #463617 * Mi Blog: http://cristianpark.sehablalinux.com/ / 2009/8/21 Martin Jansa > On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote: > > -> Still I think there's a need for a platform to promote ~working > > apps in an appealing way. > > Yes that's true and I think that opkg.org is doing just that. > > Only few small parts are missing. > > 1) Use it rather as nice showroom, not as opkg/deb repo > > 2) Voting UP/DOWN for popularity and showing most popular packages for > section/task, maybe iven UP/DOWN buttons for "I would like to test > it/use it or I need exactly something like this" - someone please > provide package for my distribution. > > 3) opkg/deb or manuall installation instructions only in first phase > when its unknown package from unknown developer :) > > 4) then community-editable list of distributions where it works/doesn't > work. > > 5) same list with sign if its included in standard repo of that > distribution > and if its not included, user should provide a link to distribution bug > tracker > where is package request for that application and everyone could provide > bbfile/src.deb as attachment in that bug, its quite easy. Distro > maintainers than could check if that package is really that popular and > if someone from users/developer itself provided working bbfile then commit > it to > their branch, remove link to bug tracker and set sign, thats already > included. > > Maybe just table like this > > | distribution | works | doesn't work | I would like to use it | Included > | Package request | > | shr-unstable | 10 + - | 2 + - | 40 + - | Yes >| link-fixed | > | shr-stable | 2 + - | 0 + - | 400 + - | No > (_Yes_) | link| > | debian | 12 + - | 0 + - | 4 + - | No > (_Yes_) | _add_link_ | > | _add new distribution_ > | > > where + - would be voting links > > > > Very last words: > > > Please do not put anything up, when there is no time / resources to > maintain it. It would be a shame to waste so much efforts > > +1! > > +1! > IMHO only few improvements of opkg.org are needed.. > > -- > uin:136542059 > jid:martin.ja...@gmail.com > Jansa Martin > sip:jama...@voip.wengo.fr > JaMa > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [da...@tuxbrain.com: Re: [ALL] New showroom for Openmoko apps]
Hello, I am the apt-portal main developer and I hope I can help extending it to support your repository. About the recently reported error when starting the web server, please make sure you use the cherrypy version provided at getdeb, check : http://wiki.getdeb.net/apt-portal/Download The cherrypy version available from the official repository repository does not work with python2.6 . Best regards, -- João Luís Marques Pinto GetDeb Team Leader http://www.getdeb.net http://blog.getdeb.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Sat, Aug 22, 2009 at 01:17:57AM +0200, David Reyes Samblas Martinez wrote: >here is the error log >mut...@iluvatar:~/apt-portal$ ./apt-portal.py playdeb >/var/lib/python-support/python2.6/sqlalchemy/util.py:7: >DeprecationWarning: the sets module is deprecated > import inspect, itertools, new, operator, sets, sys, warnings, weakref [...] >After some googling I don't find anything about this error, I will try >to dedicate some more time to solve this and if not success maybe I >will do my own php frontend based on the imported table. This is surprisingly ungooglable! But what I usually do on new Ubuntus is install python2.5 and (very cruelly) replace the symlink so that /usr/bin/python -> /usr/bin/python2.5 But the other suggestion about hacking the source might be safer, if Ubuntu is doing something in Python that actually uses 2.6 features ;) Let us know how it works out! -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 12:44:35PM +0200, Martin Jansa wrote: >On Fri, Aug 21, 2009 at 04:45:00AM -0500, KaZeR wrote: >> One problem is that distro packaged apps sometimes lag way behind bleeding >> edge. >> e.g. : navit in SHR : r2309, navit via navit's feed : r2511 : that's quite a >> lot. >I use autorev for navit as one of my tweaks of shr-unstable, so I have >always the latest. My two cents say something about stability ;) In a showroom kind of thing it's important to build a community around what would otherwise be a mod_autoindex list of /pool/ and not so much take a stance on distro management. >Bleeding-edge distro with even more autorev packages would be great even >for application developers to check their continuous integration and >build problems. Is there some Open Source tool for doing CI, something that distros would use already? I thought for a while Launchpad might be it, but probably not. >With my 2 cents we've 4 already, great! :) 6! -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 11:50:53AM +0200, Martin Jansa wrote: > >3) opkg/deb or manuall installation instructions only in first phase >when its unknown package from unknown developer :) > >4) then community-editable list of distributions where it works/doesn't >work. > >5) same list with sign if its included in standard repo of that distribution >and if its not included, user should provide a link to distribution bug tracker >where is package request for that application and everyone could provide >bbfile/src.deb as attachment in that bug, its quite easy. Distro >maintainers than could check if that package is really that popular and >if someone from users/developer itself provided working bbfile then commit it >to >their branch, remove link to bug tracker and set sign, thats already included. I haven't had time read the entire thread, so this may have been discussed, but there's so much to read I just need to get this out lest I forget it ;) Having done some integration work in the past, this idea of "distributions where it works" does not sound correct. Distros have maintainers, which means the distro's software would always work on the distro or they're doing something wrong. If this would start off by being about official packages, we would just need one installation of the site per distro, and show the contents of those distros. The logical step after that would be to have unofficial packages or packages recommended for integration or whatever, more-or-less 3rd-party packages anyway, and by then we'd have the framework in place where it either installs/works/whatever on a distro or not, and it either gets displayed on that distro's site or not. So if we use opkg.org as an example name, we would have om.opkg.org and shr.opkg.org and friends. Am I making sense?-) -- mjt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Saturday 22 August 2009 00:17:57 David Reyes Samblas Martinez wrote:
> Partial success, after installing Jaunty,
> the import proccess apt2db goes ok and I have the example repo in a sqlite
> but the web server doesn't boot up
> here is the error log
> mut...@iluvatar:~/apt-portal$ ./apt-portal.py playdeb
> /var/lib/python-support/python2.6/sqlalchemy/util.py:7:
> DeprecationWarning: the sets module is deprecated
> import inspect, itertools, new, operator, sets, sys, warnings, weakref
> Traceback (most recent call last):
> File "./apt-portal.py", line 274, in
> cherrypy.quickstart(cherrypy.root, '/', config=conf)
> File "/var/lib/python-support/python2.6/cherrypy/__init__.py", line
> 248, in quickstart
> engine.start()
> File "/var/lib/python-support/python2.6/cherrypy/process/wspbus.py",
> line 184, in start
> self.publish('start')
> File "/var/lib/python-support/python2.6/cherrypy/process/wspbus.py",
> line 147, in publish
> output.append(listener(*args, **kwargs))
> File "/var/lib/python-support/python2.6/cherrypy/_cpserver.py", line
> 90, in start
> ServerAdapter.start(self)
> File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
> line 60, in start
> self.wait()
> File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
> line 95, in wait
> raise self.interrupt
> thread.error: can't start new thread
> Exception in thread HTTPServer Thread-2:
> Traceback (most recent call last):
> File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
> self.run()
> File "/usr/lib/python2.6/threading.py", line 477, in run
> self.__target(*self.__args, **self.__kwargs)
> File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
> line 73, in _start_http_thread
> self.httpserver.start()
> File "/var/lib/python-support/python2.6/cherrypy/wsgiserver/__init__.py",
> line 1603, in start
> self.requests.start()
> File "/var/lib/python-support/python2.6/cherrypy/wsgiserver/__init__.py",
> line 1300, in start
> worker.start()
> File "/usr/lib/python2.6/threading.py", line 471, in start
> _start_new_thread(self.__bootstrap, ())
> error: can't start new thread
>
I think that cherry py in jaunty doesn't work with python 2.6 if i'm correct
you'll have to install
python 2.5 and change the top line to #!/usr/bin/python2.5 (you could check by
doing python2.5
./apt-portal.py playdeb obviously)
solar.george
signature.asc
Description: This is a digitally signed message part.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Sat, Aug 22, 2009 at 2:17 AM, David Reyes Samblas Martinez wrote: > Partial success, after installing Jaunty, > the import proccess apt2db goes ok and I have the example repo in a sqlite > but the web server doesn't boot up > here is the error log I forwarded the error to guys/devels at #getdeb, they said they'd be able to help with Jaunty. I'll let you know (or you can join the channel to ask them directly) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/21 Sebastian Krzyszkowiak :
> On 8/21/09, Risto H. Kurppa wrote:
>> On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas
>> Martinez wrote:
>>> 2009/8/21 Risto H. Kurppa :
I had a closer look at apt-portal at https://launchpad.net/apt-portal
>>>
>>> Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but
>>> fails on running the scripts
>>> Seems to need Jaunty to work out of the box, I will try to install
>>> Jaunt in some some partition and try again
>>>
>>> Risto, Yes seems a good start, I will also take a look at the
>>> internals to see how dificult will be to adapt to bb files or opkg
>>> repos
>>>
>>> [1]http://wiki.getdeb.net/apt-portal/Download
>>
>>
>> David: wow nice. Action - I like it!!
>>
>> r
>
> I like it too. opkg repositiories format is similar to apt ones, so it
> shouldn't be hard. And when someone will setup it, i'll look on
> integrating it with SHR Installer :)
>
> --
> Sebastian Krzyszkowiak
> dos
Partial success, after installing Jaunty,
the import proccess apt2db goes ok and I have the example repo in a sqlite
but the web server doesn't boot up
here is the error log
mut...@iluvatar:~/apt-portal$ ./apt-portal.py playdeb
/var/lib/python-support/python2.6/sqlalchemy/util.py:7:
DeprecationWarning: the sets module is deprecated
import inspect, itertools, new, operator, sets, sys, warnings, weakref
Traceback (most recent call last):
File "./apt-portal.py", line 274, in
cherrypy.quickstart(cherrypy.root, '/', config=conf)
File "/var/lib/python-support/python2.6/cherrypy/__init__.py", line
248, in quickstart
engine.start()
File "/var/lib/python-support/python2.6/cherrypy/process/wspbus.py",
line 184, in start
self.publish('start')
File "/var/lib/python-support/python2.6/cherrypy/process/wspbus.py",
line 147, in publish
output.append(listener(*args, **kwargs))
File "/var/lib/python-support/python2.6/cherrypy/_cpserver.py", line
90, in start
ServerAdapter.start(self)
File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
line 60, in start
self.wait()
File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
line 95, in wait
raise self.interrupt
thread.error: can't start new thread
Exception in thread HTTPServer Thread-2:
Traceback (most recent call last):
File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
self.run()
File "/usr/lib/python2.6/threading.py", line 477, in run
self.__target(*self.__args, **self.__kwargs)
File "/var/lib/python-support/python2.6/cherrypy/process/servers.py",
line 73, in _start_http_thread
self.httpserver.start()
File "/var/lib/python-support/python2.6/cherrypy/wsgiserver/__init__.py",
line 1603, in start
self.requests.start()
File "/var/lib/python-support/python2.6/cherrypy/wsgiserver/__init__.py",
line 1300, in start
worker.start()
File "/usr/lib/python2.6/threading.py", line 471, in start
_start_new_thread(self.__bootstrap, ())
error: can't start new thread
After some googling I don't find anything about this error, I will try
to dedicate some more time to solve this and if not success maybe I
will do my own php frontend based on the imported table.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
--
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable & embedded solutions
Openmoko, Openpandora, Arduino
Hey, watch out!!! There's a linux in your pocket!!!
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Risto H. Kurppa wrote: > On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas > Martinez wrote: >> 2009/8/21 Risto H. Kurppa : >>> I had a closer look at apt-portal at https://launchpad.net/apt-portal >> >> Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but >> fails on running the scripts >> Seems to need Jaunty to work out of the box, I will try to install >> Jaunt in some some partition and try again >> >> Risto, Yes seems a good start, I will also take a look at the >> internals to see how dificult will be to adapt to bb files or opkg >> repos >> >> [1]http://wiki.getdeb.net/apt-portal/Download > > > David: wow nice. Action - I like it!! > > r I like it too. opkg repositiories format is similar to apt ones, so it shouldn't be hard. And when someone will setup it, i'll look on integrating it with SHR Installer :) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 7:01 PM, David Reyes Samblas Martinez wrote: > 2009/8/21 Risto H. Kurppa : >> I had a closer look at apt-portal at https://launchpad.net/apt-portal > > Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but > fails on running the scripts > Seems to need Jaunty to work out of the box, I will try to install > Jaunt in some some partition and try again > > Risto, Yes seems a good start, I will also take a look at the > internals to see how dificult will be to adapt to bb files or opkg > repos > > [1]http://wiki.getdeb.net/apt-portal/Download David: wow nice. Action - I like it!! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/21 Risto H. Kurppa : > I had a closer look at apt-portal at https://launchpad.net/apt-portal Tried to istall on Ubuntu 8.10 machine with this instructuions[1] but fails on running the scripts Seems to need Jaunty to work out of the box, I will try to install Jaunt in some some partition and try again Risto, Yes seems a good start, I will also take a look at the internals to see how dificult will be to adapt to bb files or opkg repos [1]http://wiki.getdeb.net/apt-portal/Download -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Yeah, that makes sense - using the bb info if there's nothing else - maybe we just initially populate the frappdb from the bb files... Hmm. On the other hand, if someone writes a more detailed description on frappdb, should that description get pushed back into the bb files? Warren On Fri, Aug 21, 2009 at 9:11 AM, Sebastian Krzyszkowiak wrote: > On 8/21/09, Warren Baird wrote: > > I'm not sure about tying it directly to the bb files - it's not clear to > me > > that the formating and information appropriate for a web-based db is the > > same as what you'd want in a bb file... > > Well, list of packages would be done by scanning bb files, but > description from bb file could be displayed only, if description from > showroom database isn't present. And editing descriptions done in > "wiki way" :) What do you think about that? > > -- > Sebastian Krzyszkowiak > dos > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
I had a closer look at apt-portal at https://launchpad.net/apt-portal To me this sounds like exactly something we're looking for: - APT-Portal is a web content management system that retrieves information from a Debian APT repository and presents an application list on a user friendly format. The APT-Portal will use a Debian APT repository Packages file at it's master data source, the data will be automatically imported into a database, additional information related to packages and contained applications can be provided using human and/or automated sources. Users do not frequently search for packages, but most frequently for applications, on this assumption the information presentation will be centered around applications. The following features will be implemented: General Features: - Automated packages information import/update from Packages(.gz,/.bz2) files - Packages classification (main, optional, additional) - Translation support for the site template - List recent changes to the repository (with apturl feeds) - Support for packages/applications descriptions translation - AJAX filter/search for names, descriptions and tags Application Information - Extended Description - Best suited for web presentation, unlike the debian packages description - Screenshots - APTURLs for: main package, optional packages, additional packages. - etc.. - What else do we need?! To me it looks like that someone with skills could try this in one night and present the results with packages from a repository the next day.. Later on, some modification is required to support other file types, not only debian-style Packages. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > Maybe we should get something like frappdb.org or something like that? I like it :) [cut] -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 KapitaÅ akcyjny: 15.500.000 zÅotych (w peÅni opÅacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 04:10:05PM +0300, Risto H. Kurppa wrote: > Rui: well done trying to call! :) > And I also agree that the name opkg.org is not the best one as opk is > used in other platforms and other formats are used on FR too.. Ok, so maybe we'll just let opkg.org die then. > I think it's ok to limit us to only FR as it's a unique device at > least for now but maybe in the future there'd be a need to support > other linux phones too..? Maybe I wouldn't rule Android out too, if > people want to add Android apps there and the file formats etc support > it.. Actually, if you're not going specific on some OS then you might just as well get a domain generic enough for one, even if you simply use a subdomain for OS specifics. Maybe you don't even need to buy a domain :) How about: apps.freesmartphone.org ? :) hint hint hint Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
I like that idea. :) We could combine both approaches - a showroom for apps (making the Hall of Fame on the wiki obsolete which is kinda hard to keep up to date...) with possibility to comment on different app-distro-whatever-combinations. We could even consider having different kinds of hardware in there - FR, 1973, HTC Touch, ... Am Freitag, den 21.08.2009, 09:01 -0400 schrieb Warren Baird: > Frankly, I'm not that fond of the name opkg.org... > > As I said, I'd rather have some kind of an application database - > something that explicitly *does not* provide opkg files. > > Maybe we should get something like frappdb.org or something like that? > > Warren > > > On Fri, Aug 21, 2009 at 8:58 AM, Rui Miguel Silva Seabra > wrote: > > On Fri, Aug 21, 2009 at 01:46:05PM +0100, Rui Miguel Silva > Seabra wrote: > > On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa > wrote: > > > Opkg.org seems to be owned by the author so if the author > is not > > > co-operative (cannot be reached, doesn't answer e-mails or > jabber) > > > there's not much we or OM can do about it. > > > > Have any of these physical contacts been tried? > > > > We probably need a "foundation" of sorts to handle this kind > of things, > > anyway, but I'm willing to donate the reasonable expense in > order to buy > > the domain either from Tobias or if I manage to buy it after > expiry and > > donate it to a foundation. > > > > r...@roque:~$ whois opkg.org > > (...) > > Domain ID:D154421724-LROR > > Domain Name:OPKG.ORG > > Created On:08-Oct-2008 07:38:10 UTC > > Last Updated On:08-Dec-2008 03:51:51 UTC > > Expiration Date:08-Oct-2009 07:38:10 UTC > > Sponsoring Registrar:ASCIO Technologies, Inc. - Denmark > (R76-LROR) > > Status:OK > > Registrant ID:AT21297988-052 > > Registrant Name:Tobias Kuendig > > Registrant Organization:Tobias Kuendig > > Registrant Street1:Sagenblickweg 6 > > Registrant Street2: > > Registrant Street3: > > Registrant City:Ebikon > > Registrant State/Province: > > Registrant Postal Code:6030 > > Registrant Country:CH > > Registrant Phone:+41.793909805 > > Registrant Phone Ext.: > > Registrant FAX: > > Registrant FAX Ext.: > > Registrant Email:tobias.kuen...@gmail.com > > > Ijust tried the phone number, a woman who couldn't speak > english or french > (just german) but understood enough to answer «no Tobias». > > I guess I'll just have to try to buy opkg.org > > Rui > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > > > > -- > Warren Baird - Photographer and Digital Artist > http://www.synergisticimages.ca > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Warren Baird wrote: > I'm not sure about tying it directly to the bb files - it's not clear to me > that the formating and information appropriate for a web-based db is the > same as what you'd want in a bb file... Well, list of packages would be done by scanning bb files, but description from bb file could be displayed only, if description from showroom database isn't present. And editing descriptions done in "wiki way" :) What do you think about that? -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 3:45 PM, Warren Baird wrote: > Funnily enough, I was just thinking about posting about something very > similar to this a couple of days ago... So there are more of us who want something like this and are not happy with the current solution. Good to hear! > The model I was thinking about was actually more like the wine application > database : http://appdb.winehq.org/ - I think the model actually works > pretty well, since in theory pretty much any X application will run on the > FR, but only some will be usable. http://wiki.winehq.org/Licensing says it's GPL and the code is available there. True, existing solutions would be nice to use, one option is to check getdeb.net, I think that's very close to what we need. - support for screenshot - support for different Ubuntu versions & architecture (=distributions in our case) - voting system included I don't know anything about the backend how much work it'd be to convert it to read .bb files or something but the frontend looks promising to me. The code is available here as GPL: http://wiki.getdeb.net/WebDevelopment (well, see https://code.launchpad.net/getdeb-web ) I visited their IRC channel (#getdeb) and was told it'll not be maintained, they'll move to a new engine at some stage: https://launchpad.net/apt-portal - some features still missing like internationalization and comments. Rui: well done trying to call! And I also agree that the name opkg.org is not the best one as opk is used in other platforms and other formats are used on FR too.. FR-apps frapps I think it's ok to limit us to only FR as it's a unique device at least for now but maybe in the future there'd be a need to support other linux phones too..? Maybe I wouldn't rule Android out too, if people want to add Android apps there and the file formats etc support it.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Michael Pilgermann wrote: >> * Also create a client for FR to search & install apps > (+) low prio I would change this one into " * Integrate SHR Installer with showroom" -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Agreed, when opkg.org started I insisted a bit with Tobias so that he wouldn't make it a distribution point but a facilitator towards finding interesting apps *from*the*repos* :) Rui On Fri, Aug 21, 2009 at 09:01:56AM -0400, Warren Baird wrote: > Frankly, I'm not that fond of the name opkg.org... > > As I said, I'd rather have some kind of an application database - something > that explicitly *does not* provide opkg files. > > Maybe we should get something like frappdb.org or something like that? > > Warren > > > On Fri, Aug 21, 2009 at 8:58 AM, Rui Miguel Silva Seabra wrote: > > > On Fri, Aug 21, 2009 at 01:46:05PM +0100, Rui Miguel Silva Seabra wrote: > > > On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote: > > > > Opkg.org seems to be owned by the author so if the author is not > > > > co-operative (cannot be reached, doesn't answer e-mails or jabber) > > > > there's not much we or OM can do about it. > > > > > > Have any of these physical contacts been tried? > > > > > > We probably need a "foundation" of sorts to handle this kind of things, > > > anyway, but I'm willing to donate the reasonable expense in order to buy > > > the domain either from Tobias or if I manage to buy it after expiry and > > > donate it to a foundation. > > > > > > r...@roque:~$ whois opkg.org > > > (...) > > > Domain ID:D154421724-LROR > > > Domain Name:OPKG.ORG > > > Created On:08-Oct-2008 07:38:10 UTC > > > Last Updated On:08-Dec-2008 03:51:51 UTC > > > Expiration Date:08-Oct-2009 07:38:10 UTC > > > Sponsoring Registrar:ASCIO Technologies, Inc. - Denmark (R76-LROR) > > > Status:OK > > > Registrant ID:AT21297988-052 > > > Registrant Name:Tobias Kuendig > > > Registrant Organization:Tobias Kuendig > > > Registrant Street1:Sagenblickweg 6 > > > Registrant Street2: > > > Registrant Street3: > > > Registrant City:Ebikon > > > Registrant State/Province: > > > Registrant Postal Code:6030 > > > Registrant Country:CH > > > Registrant Phone:+41.793909805 > > > Registrant Phone Ext.: > > > Registrant FAX: > > > Registrant FAX Ext.: > > > Registrant > > > Email:tobias.kuen...@gmail.com > > > > Ijust tried the phone number, a woman who couldn't speak english or french > > (just german) but understood enough to answer «no Tobias». > > > > I guess I'll just have to try to buy opkg.org > > > > Rui > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > -- > Warren Baird - Photographer and Digital Artist > http://www.synergisticimages.ca > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Frankly, I'm not that fond of the name opkg.org... As I said, I'd rather have some kind of an application database - something that explicitly *does not* provide opkg files. Maybe we should get something like frappdb.org or something like that? Warren On Fri, Aug 21, 2009 at 8:58 AM, Rui Miguel Silva Seabra wrote: > On Fri, Aug 21, 2009 at 01:46:05PM +0100, Rui Miguel Silva Seabra wrote: > > On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote: > > > Opkg.org seems to be owned by the author so if the author is not > > > co-operative (cannot be reached, doesn't answer e-mails or jabber) > > > there's not much we or OM can do about it. > > > > Have any of these physical contacts been tried? > > > > We probably need a "foundation" of sorts to handle this kind of things, > > anyway, but I'm willing to donate the reasonable expense in order to buy > > the domain either from Tobias or if I manage to buy it after expiry and > > donate it to a foundation. > > > > r...@roque:~$ whois opkg.org > > (...) > > Domain ID:D154421724-LROR > > Domain Name:OPKG.ORG > > Created On:08-Oct-2008 07:38:10 UTC > > Last Updated On:08-Dec-2008 03:51:51 UTC > > Expiration Date:08-Oct-2009 07:38:10 UTC > > Sponsoring Registrar:ASCIO Technologies, Inc. - Denmark (R76-LROR) > > Status:OK > > Registrant ID:AT21297988-052 > > Registrant Name:Tobias Kuendig > > Registrant Organization:Tobias Kuendig > > Registrant Street1:Sagenblickweg 6 > > Registrant Street2: > > Registrant Street3: > > Registrant City:Ebikon > > Registrant State/Province: > > Registrant Postal Code:6030 > > Registrant Country:CH > > Registrant Phone:+41.793909805 > > Registrant Phone Ext.: > > Registrant FAX: > > Registrant FAX Ext.: > > Registrant Email:tobias.kuen...@gmail.com > > Ijust tried the phone number, a woman who couldn't speak english or french > (just german) but understood enough to answer «no Tobias». > > I guess I'll just have to try to buy opkg.org > > Rui > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 01:46:05PM +0100, Rui Miguel Silva Seabra wrote: > On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote: > > Opkg.org seems to be owned by the author so if the author is not > > co-operative (cannot be reached, doesn't answer e-mails or jabber) > > there's not much we or OM can do about it. > > Have any of these physical contacts been tried? > > We probably need a "foundation" of sorts to handle this kind of things, > anyway, but I'm willing to donate the reasonable expense in order to buy > the domain either from Tobias or if I manage to buy it after expiry and > donate it to a foundation. > > r...@roque:~$ whois opkg.org > (...) > Domain ID:D154421724-LROR > Domain Name:OPKG.ORG > Created On:08-Oct-2008 07:38:10 UTC > Last Updated On:08-Dec-2008 03:51:51 UTC > Expiration Date:08-Oct-2009 07:38:10 UTC > Sponsoring Registrar:ASCIO Technologies, Inc. - Denmark (R76-LROR) > Status:OK > Registrant ID:AT21297988-052 > Registrant Name:Tobias Kuendig > Registrant Organization:Tobias Kuendig > Registrant Street1:Sagenblickweg 6 > Registrant Street2: > Registrant Street3: > Registrant City:Ebikon > Registrant State/Province: > Registrant Postal Code:6030 > Registrant Country:CH > Registrant Phone:+41.793909805 > Registrant Phone Ext.: > Registrant FAX: > Registrant FAX Ext.: > Registrant Email:tobias.kuen...@gmail.com Ijust tried the phone number, a woman who couldn't speak english or french (just german) but understood enough to answer «no Tobias». I guess I'll just have to try to buy opkg.org Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 03:25:25PM +0300, Risto H. Kurppa wrote: > Opkg.org seems to be owned by the author so if the author is not > co-operative (cannot be reached, doesn't answer e-mails or jabber) > there's not much we or OM can do about it. Have any of these physical contacts been tried? We probably need a "foundation" of sorts to handle this kind of things, anyway, but I'm willing to donate the reasonable expense in order to buy the domain either from Tobias or if I manage to buy it after expiry and donate it to a foundation. r...@roque:~$ whois opkg.org (...) Domain ID:D154421724-LROR Domain Name:OPKG.ORG Created On:08-Oct-2008 07:38:10 UTC Last Updated On:08-Dec-2008 03:51:51 UTC Expiration Date:08-Oct-2009 07:38:10 UTC Sponsoring Registrar:ASCIO Technologies, Inc. - Denmark (R76-LROR) Status:OK Registrant ID:AT21297988-052 Registrant Name:Tobias Kuendig Registrant Organization:Tobias Kuendig Registrant Street1:Sagenblickweg 6 Registrant Street2: Registrant Street3: Registrant City:Ebikon Registrant State/Province: Registrant Postal Code:6030 Registrant Country:CH Registrant Phone:+41.793909805 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:tobias.kuen...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Funnily enough, I was just thinking about posting about something very similar to this a couple of days ago... I definitely agree that opkg.org is broken in many ways, and impossible to fix atm. And I think some kind of application database is very important. The model I was thinking about was actually more like the wine application database : http://appdb.winehq.org/ - I think the model actually works pretty well, since in theory pretty much any X application will run on the FR, but only some will be usable. I wasn't able to find out in a quick scan if the code for the wine appdb is available, but I suspect it is - maybe we should just use something like that as a base? I definitely think we need something web-based, with the capability for voting, comments, etc. If I were to do it, from scratch, I'd probably use django, but I think it's worth exploring other options first. Are their other open source app databases we might be able to reuse? I'm not sure about tying it directly to the bb files - it's not clear to me that the formating and information appropriate for a web-based db is the same as what you'd want in a bb file... Warren On Fri, Aug 21, 2009 at 8:25 AM, Risto H. Kurppa wrote: > Opkg.org seems to be owned by the author so if the author is not > co-operative (cannot be reached, doesn't answer e-mails or jabber) > there's not much we or OM can do about it. > > Summa summarum: > > * Looks like there are people around who support the idea of showroom. > * Showroom, not a repository > * Read the data from packages in the repositories of the distributions > * Allow filtering of packages based on existing desktop files and > categories > * Allow social features like comments & voting on the web site > * Also create a client for FR to search & install apps > > Did I miss something? > > Anyone with the skills around willing to work on this? I'd say the one > who has the skills can decide the technology, be it git+django or > svn+php or whatever, as long as it's possible for more than one people > to contribute. > > r > > > On Fri, Aug 21, 2009 at 2:17 PM, David Reyes Samblas > Martinez wrote: > > 2009/8/21 Risto H. Kurppa : > >> On Fri, Aug 21, 2009 at 1:12 PM, Sebastian > >> Krzyszkowiak wrote: > >>> On 8/21/09, David Reyes Samblas Martinez wrote: > Just an idea, why not use the bb file and source files as README, > INSTALL, Changelog, and .desktop files if exist as source for this > showroom? > >> > >>> ++ from me! Some way for browse repository (doesn't matter if from WWW > >>> or from app on Neo, or even both at once) could be IMO the best > >>> showroom. It won't be outdated, app authors won't have to package > >>> their apps (as now they do, which is strange ;x). > >> > >> I agree, the point is to make it easy and appealing to find cool apps. > >> But I wouldn't like to be able to see descriptions of all libraries > >> but apps that one can use to do cool stuff. > > the existance or not of desktop file can be used as filter to not > > include libs/console apps if you don't want them, (maybe others are > > searching for a lib and can be useful to include them) > >> > >> If it can be automated this far, it'd be great! Both WWW and app for > >> Openmoko would be nice to have. And somehow - this again should be > >> distro-undependant so that it can be easily adapted to work on > >> openwrt, shr, om2009 - maybe even on Debian and Gentoo?! > > I'm not familiar with the openwrt and Debian(There is a text file with > > descriptions of the repo, isn't) it the Package system but if they > > have a description field I don't know why it shoudn't be included, the > > work will be to match all those sources of infomation and find a good > > balance to show attractive/useful information , > > > > A other idea regarding this is use a filter to show all, or just > > one/few distros, and when entering the app description show on what > > distribution is included an in what version. > > > > Yes its no easy and maybe we must start easy with just one package > > system (read SHR ;) ) and then move one adding more distros and > > finding good ways to merge all this information to this showing room > > system. > > > >> > >> r > >> > >> -- > >> | risto h. kurppa > >> | risto at kurppa dot fi > >> | http://risto.kurppa.fi > >> > >> ___ > >> Openmoko community mailing list > >> community@lists.openmoko.org > >> http://lists.openmoko.org/mailman/listinfo/community > >> > > > > > > > > -- > > David Reyes Samblas Martinez > > http://www.tuxbrain.com > > Open ultraportable & embedded solutions > > Openmoko, Openpandora, Arduino > > Hey, watch out!!! There's a linux in your pocket!!! > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.
Re: [ALL] New showroom for Openmoko apps
Original-Nachricht > Datum: Fri, 21 Aug 2009 15:25:25 +0300 > Von: "Risto H. Kurppa" > An: List for Openmoko community discussion > Betreff: Re: [ALL] New showroom for Openmoko apps > Opkg.org seems to be owned by the author so if the author is not > co-operative (cannot be reached, doesn't answer e-mails or jabber) > there's not much we or OM can do about it. > > Summa summarum: > > * Looks like there are people around who support the idea of showroom. + > * Showroom, not a repository + > * Read the data from packages in the repositories of the distributions + > * Allow filtering of packages based on existing desktop files and > categories + > * Allow social features like comments & voting on the web site + > * Also create a client for FR to search & install apps (+) low prio > > Did I miss something? > > Anyone with the skills around willing to work on this? I'd say the one > who has the skills can decide the technology, be it git+django or > svn+php or whatever, - ... we don't need source file management here I think; let's use stuff available on gforge instead. Let's concentrate on presentation and information (not the development) ... > as long as it's possible for more than one people > to contribute. > > r > > > On Fri, Aug 21, 2009 at 2:17 PM, David Reyes Samblas > Martinez wrote: > > 2009/8/21 Risto H. Kurppa : > >> On Fri, Aug 21, 2009 at 1:12 PM, Sebastian > >> Krzyszkowiak wrote: > >>> On 8/21/09, David Reyes Samblas Martinez wrote: > >>>> Just an idea, why not use the bb file and source files as README, > >>>> INSTALL, Changelog, and .desktop files if exist as source for this > >>>> showroom? > >> > >>> ++ from me! Some way for browse repository (doesn't matter if from WWW > >>> or from app on Neo, or even both at once) could be IMO the best > >>> showroom. It won't be outdated, app authors won't have to package > >>> their apps (as now they do, which is strange ;x). > >> > >> I agree, the point is to make it easy and appealing to find cool apps. > >> But I wouldn't like to be able to see descriptions of all libraries > >> but apps that one can use to do cool stuff. > > the existance or not of desktop file can be used as filter to not > > include libs/console apps if you don't want them, (maybe others are > > searching for a lib and can be useful to include them) > >> > >> If it can be automated this far, it'd be great! Both WWW and app for > >> Openmoko would be nice to have. And somehow - this again should be > >> distro-undependant so that it can be easily adapted to work on > >> openwrt, shr, om2009 - maybe even on Debian and Gentoo?! > > I'm not familiar with the openwrt and Debian(There is a text file with > > descriptions of the repo, isn't) it the Package system but if they > > have a description field I don't know why it shoudn't be included, the > > work will be to match all those sources of infomation and find a good > > balance to show attractive/useful information , > > > > A other idea regarding this is use a filter to show all, or just > > one/few distros, and when entering the app description show on what > > distribution is included an in what version. > > > > Yes its no easy and maybe we must start easy with just one package > > system (read SHR ;) ) and then move one adding more distros and > > finding good ways to merge all this information to this showing room > > system. > > > >> > >> r > >> > >> -- > >> | risto h. kurppa > >> | risto at kurppa dot fi > >> | http://risto.kurppa.fi > >> > >> ___ > >> Openmoko community mailing list > >> community@lists.openmoko.org > >> http://lists.openmoko.org/mailman/listinfo/community > >> > > > > > > > > -- > > David Reyes Samblas Martinez > > http://www.tuxbrain.com > > Open ultraportable & embedded solutions > > Openmoko, Openpandora, Arduino > > Hey, watch out!!! There's a linux in your pocket!!! > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Opkg.org seems to be owned by the author so if the author is not co-operative (cannot be reached, doesn't answer e-mails or jabber) there's not much we or OM can do about it. Summa summarum: * Looks like there are people around who support the idea of showroom. * Showroom, not a repository * Read the data from packages in the repositories of the distributions * Allow filtering of packages based on existing desktop files and categories * Allow social features like comments & voting on the web site * Also create a client for FR to search & install apps Did I miss something? Anyone with the skills around willing to work on this? I'd say the one who has the skills can decide the technology, be it git+django or svn+php or whatever, as long as it's possible for more than one people to contribute. r On Fri, Aug 21, 2009 at 2:17 PM, David Reyes Samblas Martinez wrote: > 2009/8/21 Risto H. Kurppa : >> On Fri, Aug 21, 2009 at 1:12 PM, Sebastian >> Krzyszkowiak wrote: >>> On 8/21/09, David Reyes Samblas Martinez wrote: Just an idea, why not use the bb file and source files as README, INSTALL, Changelog, and .desktop files if exist as source for this showroom? >> >>> ++ from me! Some way for browse repository (doesn't matter if from WWW >>> or from app on Neo, or even both at once) could be IMO the best >>> showroom. It won't be outdated, app authors won't have to package >>> their apps (as now they do, which is strange ;x). >> >> I agree, the point is to make it easy and appealing to find cool apps. >> But I wouldn't like to be able to see descriptions of all libraries >> but apps that one can use to do cool stuff. > the existance or not of desktop file can be used as filter to not > include libs/console apps if you don't want them, (maybe others are > searching for a lib and can be useful to include them) >> >> If it can be automated this far, it'd be great! Both WWW and app for >> Openmoko would be nice to have. And somehow - this again should be >> distro-undependant so that it can be easily adapted to work on >> openwrt, shr, om2009 - maybe even on Debian and Gentoo?! > I'm not familiar with the openwrt and Debian(There is a text file with > descriptions of the repo, isn't) it the Package system but if they > have a description field I don't know why it shoudn't be included, the > work will be to match all those sources of infomation and find a good > balance to show attractive/useful information , > > A other idea regarding this is use a filter to show all, or just > one/few distros, and when entering the app description show on what > distribution is included an in what version. > > Yes its no easy and maybe we must start easy with just one package > system (read SHR ;) ) and then move one adding more distros and > finding good ways to merge all this information to this showing room > system. > >> >> r >> >> -- >> | risto h. kurppa >> | risto at kurppa dot fi >> | http://risto.kurppa.fi >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/21 Risto H. Kurppa : > On Fri, Aug 21, 2009 at 1:12 PM, Sebastian > Krzyszkowiak wrote: >> On 8/21/09, David Reyes Samblas Martinez wrote: >>> Just an idea, why not use the bb file and source files as README, >>> INSTALL, Changelog, and .desktop files if exist as source for this >>> showroom? > >> ++ from me! Some way for browse repository (doesn't matter if from WWW >> or from app on Neo, or even both at once) could be IMO the best >> showroom. It won't be outdated, app authors won't have to package >> their apps (as now they do, which is strange ;x). > > I agree, the point is to make it easy and appealing to find cool apps. > But I wouldn't like to be able to see descriptions of all libraries > but apps that one can use to do cool stuff. the existance or not of desktop file can be used as filter to not include libs/console apps if you don't want them, (maybe others are searching for a lib and can be useful to include them) > > If it can be automated this far, it'd be great! Both WWW and app for > Openmoko would be nice to have. And somehow - this again should be > distro-undependant so that it can be easily adapted to work on > openwrt, shr, om2009 - maybe even on Debian and Gentoo?! I'm not familiar with the openwrt and Debian(There is a text file with descriptions of the repo, isn't) it the Package system but if they have a description field I don't know why it shoudn't be included, the work will be to match all those sources of infomation and find a good balance to show attractive/useful information , A other idea regarding this is use a filter to show all, or just one/few distros, and when entering the app description show on what distribution is included an in what version. Yes its no easy and maybe we must start easy with just one package system (read SHR ;) ) and then move one adding more distros and finding good ways to merge all this information to this showing room system. > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Patryk Benderz wrote: >> Official Openmoko distributions are Om2009 and SHR (as now it's > Really? I have just checked here: > http://wiki.openmoko.org/wiki/Distributions#Official_Openmoko_releases > and SHR is not listed as official. Should it be updated? Openmoko Inc. is no longer supporting Freerunner, so there is no "official openmoko distribution" now. By "Openmoko" I mean Om2009 and FSO official distro. And FSO official distro is now SHR. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > So what? Then such "showroom" should have Android, OpenWrt, Qtopia, > OE, Gentoo, Debian, Arch... and other versions of packages for one > app? Who'll package it then? Application developer? Showroom > maintainer? Please be serious... and that is exactly why "Showroom" should be showroom only - not a repository. Packages should be maintained at distro level with bb recipes. > > Official Openmoko distributions are Om2009 and SHR (as now it's Really? I have just checked here: http://wiki.openmoko.org/wiki/Distributions#Official_Openmoko_releases and SHR is not listed as official. Should it be updated? [cut] > We're talking about "Openmoko" apps here. Other distro maintainers > (like Debian, OpenWrt etc.) have to care about their repositories on This topic is _not_ about repositories, look at the subject. > their own. So they can post informations how to get in their repos, > but on their own, on theirs sites or threads on ml. But if we're > talking about Openmoko, then I can't see any better choise than > sending recipe for shr-devel maillist, even, if it's target isn't only > SHR. > > > btw: i don't recall to be this list shr centric, so please post your "shr > > rulz" stuff at the shr lists. > > Ok, so we can't talk about any distro here, cause it isn't "Android > centric"? I can't recommend Debian for someone here, cause it's not > "Debian centric"? Be serious! ...be calm > > SHR has the best system to send new recipes. If something else would > have better, then i'd talk now about that, not SHR. Again, don't make > people idiots, cause in majority of cases person who does that shows > that he's idiot himself! ...easy, if we start fighting, there will be no time left for coding. -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 KapitaÅ akcyjny: 15.500.000 zÅotych (w peÅni opÅacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 11:59:30AM +0200, Sebastian Krzyszkowiak wrote: > On 8/21/09, Martin Jansa wrote: > > On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote: > >> -> Still I think there's a need for a platform to promote ~working > >> apps in an appealing way. > > > > Yes that's true and I think that opkg.org is doing just that. > > > > Only few small parts are missing. > > > > 1) Use it rather as nice showroom, not as opkg/deb repo > > > > 2) Voting UP/DOWN for popularity and showing most popular packages for > > section/task, maybe iven UP/DOWN buttons for "I would like to test > > it/use it or I need exactly something like this" - someone please > > provide package for my distribution. > > > > 3) opkg/deb or manuall installation instructions only in first phase > > when its unknown package from unknown developer :) > > > > 4) then community-editable list of distributions where it works/doesn't > > work. > > > > 5) same list with sign if its included in standard repo of that distribution > > and if its not included, user should provide a link to distribution bug > > tracker > > where is package request for that application and everyone could provide > > bbfile/src.deb as attachment in that bug, its quite easy. Distro > > maintainers than could check if that package is really that popular and > > if someone from users/developer itself provided working bbfile then commit > > it to > > their branch, remove link to bug tracker and set sign, thats already > > included. > > > > Maybe just table like this > > > > | distribution | works | doesn't work | I would like to use it | Included > > | Package request | > > | shr-unstable | 10 + - | 2 + - | 40 + - | Yes > > | link-fixed | > > | shr-stable | 2 + - | 0 + - | 400 + - | No > > (_Yes_) | link| > > | debian | 12 + - | 0 + - | 4 + - | No > > (_Yes_) | _add_link_ | > > | _add new distribution_ > > | > > > > where + - would be voting links > > > >> > Very last words: > >> > Please do not put anything up, when there is no time / resources to > >> > maintain it. It would be a shame to waste so much efforts > >> +1! > > > > +1! > > IMHO only few improvements of opkg.org are needed.. > > I have one idea: how do you want to catch up with library changes > (versioning, naming etc.) on those distributrions? Now on opkg.org > there are lots of nice, but unusable apps, because authors forget > about that apps and there is noone who could regenerate package. That's why I suggested 3) to use opkg/deb or manuall installation instructions only in first phase Because someone brave enough should be able to install it manually, test provided opkg/deb or use install instruction for creating bbfile. And then add his vote for "works". If he cannot built/run it, maybe didn't even tried to install and just likes screenshots+description, add vote for "I would like to use it". This vote would be usefull also for end users without time or skills to built it on their own or to mess with library changes and so. I'm willing to try to provide bbfiles for packages with high "I would like to use it" which are now without bbfile (as I tried ie with PISI). So whole reason for this table would be to prioritize including of packages to distributions based on count of works or likes. -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa pgpWPjryRYhmZ.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/21 Michal Brzozowski : > Sounds like a good idea. But don't forget other features that people demand. > Voting, popularity ranks, comments, testing reports on various distros, etc. > We need a website in my opinion. Nothing stops a frontend to add features to the basic showing functionality, for example the web frontend can also include those social features to users to comment and rate the app, but the phone front end just implement a search/install feature. The idea is to define a good base to free/easey the developer/matainers the work of upload an aplication somewhere else than a repository. > > 2009/8/21 David Reyes Samblas Martinez >> >> Just an idea, why not use the bb file and source files as README, >> INSTALL, Changelog, and .desktop files if exist as source for this >> showroom? >> bb files has a DESCRIPTION field that can be a little wikified (==, *, >> ) to have a bare minimum presentation card and can be enriched with >> the other files , also if the desktop file is well categorized can >> also be used to create a first level navigation. >> >> I think this can be a incentive to devels and distro/packages >> mantainers to take care of the categorization than can be reused by >> other initiatives as launchers, and package installers. >> >> The only thing is not clear with this approach is the >> screeenshots/images stuff, but maybe is not hard to standardize a >> directory name in the sources like src/screenshots and upload those >> images in the web front end. >> >> Please don't blame to much if all the avobe has no sense. >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > It does not look good! Wiki is a nice idea, freely editable for > everyone - but it just doesn't work for all purposes. Such a showroom doesn't need to look fancy - it has to be informative! Something like: http://wiki.openmoko.org/index.php?title=Main_Page/pl&oldid=40837 is nice enough for me. And i bet it is not that hard to make it look fancy at wiki if you really want to. [cut] > Can't get RSS out with comments. Wiki doesn't create a repository. And > - it doesn't look appealing! 1.You didn't mention RSS earlier. 2.This topic is about creating Showroom - not about repo. 3.same as before - it has to be informative in first place, then we can look after good look. [cut] > Not? See http://www.opkg.org/packages ... Sorry, didn't noticed these two files: Packages Packages.gz You are right, opkg is a repository. A poor one which doesn't include dependencies. Regardless of above, you started this topic with subject "New showroom for Openmoko apps", not "New repo..." [cut] > Have tried to do that for ~6 months now. ...to contact with him, or to convince him? Did you investigate status of opkg.org domain? Is it bought by this guy or sponsored by OpenMoko? Someone mentioned that opkg.org source code is available. If domain is sponsored by OM or else, than IMHO after half year of catching author you can ask OM to hand it over to someone else, maybe you? Looks like a flame - going to look aronud for an extinguisher ;) P.S. Did you noticed i am doing my best to change my signature to correct before posting to ML?... manually... -- Kind Regards, Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 04:45:00AM -0500, KaZeR wrote: > One problem is that distro packaged apps sometimes lag way behind bleeding > edge. > e.g. : navit in SHR : r2309, navit via navit's feed : r2511 : that's quite a > lot. > > It's not a criticism, just my 2 cents :) And sometimes its vice-versa, I'm building my own version of shr-unstable with my tweaks and images contains everything I use, so its ready to use after flashing. Many packages in shr-unstable are autorev, that means with every rebuild of install image, all autorev packages are checked if new code was commited to their repository and if so, rebuilded with that new code. I use autorev for navit as one of my tweaks of shr-unstable, so I have always the latest. Bleeding-edge distro with even more autorev packages would be great even for application developers to check their continuous integration and build problems. With my 2 cents we've 4 already, great! :) -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa pgpqCMTY6j1B2.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Risto H. Kurppa wrote: > On Fri, Aug 21, 2009 at 1:12 PM, Sebastian > Krzyszkowiak wrote: >> On 8/21/09, David Reyes Samblas Martinez wrote: >>> Just an idea, why not use the bb file and source files as README, >>> INSTALL, Changelog, and .desktop files if exist as source for this >>> showroom? > >> ++ from me! Some way for browse repository (doesn't matter if from WWW >> or from app on Neo, or even both at once) could be IMO the best >> showroom. It won't be outdated, app authors won't have to package >> their apps (as now they do, which is strange ;x). > > I agree, the point is to make it easy and appealing to find cool apps. > But I wouldn't like to be able to see descriptions of all libraries > but apps that one can use to do cool stuff. > > If it can be automated this far, it'd be great! Both WWW and app for > Openmoko would be nice to have. And somehow - this again should be > distro-undependant so that it can be easily adapted to work on > openwrt, shr, om2009 - maybe even on Debian and Gentoo?! I already started shr-installer. It's based on PackageKit, so it shouldn't be hard to use it in different distro. We could work on top on it. And about libraries - just filter them out! ;) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
I dont think its a good idea to have the app showroom just "browse" a distribution repository. However, ... If the showroom is made so that it uses bb files etc, to get the application information. Then getting your application into the showroom would also imply that it gets into the distributions. Adolph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 1:12 PM, Sebastian Krzyszkowiak wrote: > On 8/21/09, David Reyes Samblas Martinez wrote: >> Just an idea, why not use the bb file and source files as README, >> INSTALL, Changelog, and .desktop files if exist as source for this >> showroom? > ++ from me! Some way for browse repository (doesn't matter if from WWW > or from app on Neo, or even both at once) could be IMO the best > showroom. It won't be outdated, app authors won't have to package > their apps (as now they do, which is strange ;x). I agree, the point is to make it easy and appealing to find cool apps. But I wouldn't like to be able to see descriptions of all libraries but apps that one can use to do cool stuff. If it can be automated this far, it'd be great! Both WWW and app for Openmoko would be nice to have. And somehow - this again should be distro-undependant so that it can be easily adapted to work on openwrt, shr, om2009 - maybe even on Debian and Gentoo?! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Sounds like a good idea. But don't forget other features that people demand. Voting, popularity ranks, comments, testing reports on various distros, etc. We need a website in my opinion. 2009/8/21 David Reyes Samblas Martinez > Just an idea, why not use the bb file and source files as README, > INSTALL, Changelog, and .desktop files if exist as source for this > showroom? > bb files has a DESCRIPTION field that can be a little wikified (==, *, > ) to have a bare minimum presentation card and can be enriched with > the other files , also if the desktop file is well categorized can > also be used to create a first level navigation. > > I think this can be a incentive to devels and distro/packages > mantainers to take care of the categorization than can be reused by > other initiatives as launchers, and package installers. > > The only thing is not clear with this approach is the > screeenshots/images stuff, but maybe is not hard to standardize a > directory name in the sources like src/screenshots and upload those > images in the web front end. > > Please don't blame to much if all the avobe has no sense. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, David Reyes Samblas Martinez wrote: > Just an idea, why not use the bb file and source files as README, > INSTALL, Changelog, and .desktop files if exist as source for this > showroom? > bb files has a DESCRIPTION field that can be a little wikified (==, *, > ) to have a bare minimum presentation card and can be enriched with > the other files , also if the desktop file is well categorized can > also be used to create a first level navigation. > > I think this can be a incentive to devels and distro/packages > mantainers to take care of the categorization than can be reused by > other initiatives as launchers, and package installers. > > The only thing is not clear with this approach is the > screeenshots/images stuff, but maybe is not hard to standardize a > directory name in the sources like src/screenshots and upload those > images in the web front end. > > Please don't blame to much if all the avobe has no sense. ++ from me! Some way for browse repository (doesn't matter if from WWW or from app on Neo, or even both at once) could be IMO the best showroom. It won't be outdated, app authors won't have to package their apps (as now they do, which is strange ;x). Once again, nice idea! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Just an idea, why not use the bb file and source files as README, INSTALL, Changelog, and .desktop files if exist as source for this showroom? bb files has a DESCRIPTION field that can be a little wikified (==, *, ) to have a bare minimum presentation card and can be enriched with the other files , also if the desktop file is well categorized can also be used to create a first level navigation. I think this can be a incentive to devels and distro/packages mantainers to take care of the categorization than can be reused by other initiatives as launchers, and package installers. The only thing is not clear with this approach is the screeenshots/images stuff, but maybe is not hard to standardize a directory name in the sources like src/screenshots and upload those images in the web front end. Please don't blame to much if all the avobe has no sense. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Sebastian Krzyszkowiak wrote: > I have one idea: how do you want to catch up with library changes > (...) STFU, s/idea/question/. It's still a little bit too early for me :x -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Martin Jansa wrote: > On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote: >> -> Still I think there's a need for a platform to promote ~working >> apps in an appealing way. > > Yes that's true and I think that opkg.org is doing just that. > > Only few small parts are missing. > > 1) Use it rather as nice showroom, not as opkg/deb repo > > 2) Voting UP/DOWN for popularity and showing most popular packages for > section/task, maybe iven UP/DOWN buttons for "I would like to test > it/use it or I need exactly something like this" - someone please > provide package for my distribution. > > 3) opkg/deb or manuall installation instructions only in first phase > when its unknown package from unknown developer :) > > 4) then community-editable list of distributions where it works/doesn't > work. > > 5) same list with sign if its included in standard repo of that distribution > and if its not included, user should provide a link to distribution bug > tracker > where is package request for that application and everyone could provide > bbfile/src.deb as attachment in that bug, its quite easy. Distro > maintainers than could check if that package is really that popular and > if someone from users/developer itself provided working bbfile then commit > it to > their branch, remove link to bug tracker and set sign, thats already > included. > > Maybe just table like this > > | distribution | works | doesn't work | I would like to use it | Included > | Package request | > | shr-unstable | 10 + - | 2 + - | 40 + - | Yes > | link-fixed | > | shr-stable | 2 + - | 0 + - | 400 + - | No > (_Yes_) | link| > | debian | 12 + - | 0 + - | 4 + - | No > (_Yes_) | _add_link_ | > | _add new distribution_ > | > > where + - would be voting links > >> > Very last words: >> > Please do not put anything up, when there is no time / resources to >> > maintain it. It would be a shame to waste so much efforts >> +1! > > +1! > IMHO only few improvements of opkg.org are needed.. I have one idea: how do you want to catch up with library changes (versioning, naming etc.) on those distributrions? Now on opkg.org there are lots of nice, but unusable apps, because authors forget about that apps and there is noone who could regenerate package. And about Android, Qtopia and iPhone "showrooms": that systems doesn't have repositories at all, only "showrooms". I think that's the main difference. I just think we should have some nice way to distribute community apps. And in my opinion sites like opkg.org makes it harder... Maybe in short-term it does what it should, but in long-term that approach just doesn't work. And actual state of opkg.org proved that. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
2009/8/21 Martin Jansa > IMHO only few improvements of opkg.org are needed.. > I agree. And since the opkg.org source code is available, we can add those improvements, fix the few bugs, and put it somewhere like www.openmoko.org/showroom (if we don't manage to contact opkg.org author) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 12:13:04PM +0300, Risto H. Kurppa wrote: > -> Still I think there's a need for a platform to promote ~working > apps in an appealing way. Yes that's true and I think that opkg.org is doing just that. Only few small parts are missing. 1) Use it rather as nice showroom, not as opkg/deb repo 2) Voting UP/DOWN for popularity and showing most popular packages for section/task, maybe iven UP/DOWN buttons for "I would like to test it/use it or I need exactly something like this" - someone please provide package for my distribution. 3) opkg/deb or manuall installation instructions only in first phase when its unknown package from unknown developer :) 4) then community-editable list of distributions where it works/doesn't work. 5) same list with sign if its included in standard repo of that distribution and if its not included, user should provide a link to distribution bug tracker where is package request for that application and everyone could provide bbfile/src.deb as attachment in that bug, its quite easy. Distro maintainers than could check if that package is really that popular and if someone from users/developer itself provided working bbfile then commit it to their branch, remove link to bug tracker and set sign, thats already included. Maybe just table like this | distribution | works | doesn't work | I would like to use it | Included | Package request | | shr-unstable | 10 + - | 2 + - | 40 + - | Yes | link-fixed | | shr-stable | 2 + - | 0 + - | 400 + - | No (_Yes_) | link| | debian | 12 + - | 0 + - | 4 + - | No (_Yes_) | _add_link_ | | _add new distribution_ | where + - would be voting links > > Very last words: > > Please do not put anything up, when there is no time / resources to > > maintain it. It would be a shame to waste so much efforts > +1! +1! IMHO only few improvements of opkg.org are needed.. -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa pgpdwM3VjcXG7.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, KaZeR wrote: > > > > Sebastian Krzyszkowiak wrote: >> >> My opinion is simple. Developer of app provides bb file (or asks >> someone to write it) and then all distros provide that app in repo. >> And that's all. >> >> That's distro maintainers who should do packages, not app developers! >> When app developers do packaging, then resulting pkgs are outdated and >> unusable after some not-so-long time. When it's added into >> distribution build system, then the only problem can be compilation >> error. That's why I think there is no need for pages like opkg.org, >> eventually for very simple apps without any special dependences. >> > > One problem is that distro packaged apps sometimes lag way behind bleeding > edge. > e.g. : navit in SHR : r2309, navit via navit's feed : r2511 : that's quite a > lot. > > It's not a criticism, just my 2 cents :) Open ticket or bug someone on IRC and it'll be fixed ;) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Sebastian Krzyszkowiak wrote: > > My opinion is simple. Developer of app provides bb file (or asks > someone to write it) and then all distros provide that app in repo. > And that's all. > > That's distro maintainers who should do packages, not app developers! > When app developers do packaging, then resulting pkgs are outdated and > unusable after some not-so-long time. When it's added into > distribution build system, then the only problem can be compilation > error. That's why I think there is no need for pages like opkg.org, > eventually for very simple apps without any special dependences. > One problem is that distro packaged apps sometimes lag way behind bleeding edge. e.g. : navit in SHR : r2309, navit via navit's feed : r2511 : that's quite a lot. It's not a criticism, just my 2 cents :) -- View this message in context: http://n2.nabble.com/ALL-New-showroom-for-Openmoko-apps-tp3479097p3487620.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Arne & Sebastian, let's try to cool down. Sebastian: if you don't agree that something like this is needed, fine, thanks for letting us know, now would you please let us to work on it if we want. Android already has it's own showroom (as pointed out in the original mail). So does QT extended: http://qtextended.org/modules/mydownloads/ AFAIK, openwrt doesn't so I'd be happy to include openwrt here. Debian has it's own project to include screenshots to package descriptions (can't find it now) and some graphical tools - but still, I'd be happy to include Debian so that it's Freerunner-users could easily find nice apps specifically targetted for Freerunner. This same goes with Gentoo, unless it alread has a project to show Freerunner-specific applications. -> I want to get the distros covered that don't have a showroom. But if there's already an existing one, I'm more than happy to point that out to both devels and users. And Openmoko wiki or projecst don't count. Amount of work: I have no idea how it's possible that opkg.org has 127 packages here: http://www.opkg.org/list.txt - I guess people have submitted it there! So when someone creates a package (or .bb recipe or whatever needed) to be submitted to a distribution, the information of the app in that distribution could be added to this new showroom. If all openembedded distros will eventually use the openembedded repositories, we can have one distro there covering SHR, OM2009 etc. And yes, Om2009 is still developed, maybe it doesn't have it's own website, mailing lists etc but it's still develoepd and there's a plan to move over to openembedded repositories instead of maintaining own repositories. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> So what? Then such "showroom" should have Android, OpenWrt, Qtopia, > OE, Gentoo, Debian, Arch... and other versions of packages for one > Ok, so we can't talk about any distro here, cause it isn't "Android > centric"? I can't recommend Debian for someone here, cause it's not > "Debian centric"? Be serious! you are obviously unwilling to think even a little bit. > SHR has the best system to send new recipes. If something else would > have better, then i'd talk now about that, not SHR. Again, don't make > people idiots, cause in majority of cases person who does that shows > that he's idiot himself! well, whatever you are taking -- double the dose or go cold tureky. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Risto H. Kurppa wrote: >>Regardless of the above, we should not compare Ubuntu/Debian >> repositories with opkg.org, simply because opkg is not repository. > > Not? See http://www.opkg.org/packages ... It is, but it really shouldn't be and that repo just sucks. People who don't know about that use that repo and then complain why something is broken :/ -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, arne anka wrote: >> Maybe you don't know, but SHR is based on OpenEmbedded, so every >> Openmoko OE based distro can benefit from bb files in SHR (and after >> commiting our work to org.openembedded.dev not only Openmoko distros >> will be able to use that). > > ok, i try again: not every distribution used on the fr is based on oe. > was that easier to grasp? So what? Then such "showroom" should have Android, OpenWrt, Qtopia, OE, Gentoo, Debian, Arch... and other versions of packages for one app? Who'll package it then? Application developer? Showroom maintainer? Please be serious... Official Openmoko distributions are Om2009 and SHR (as now it's freesmartphone.org distribution), and majority of "distros" available are based on one of them. Sending bb recipe to SHR is simplier than for Om2009, and sending it for one of them makes it available in second one sooner or later. And ATM it seems Om2009 isn't developed so actively. We're talking about "Openmoko" apps here. Other distro maintainers (like Debian, OpenWrt etc.) have to care about their repositories on their own. So they can post informations how to get in their repos, but on their own, on theirs sites or threads on ml. But if we're talking about Openmoko, then I can't see any better choise than sending recipe for shr-devel maillist, even, if it's target isn't only SHR. > btw: i don't recall to be this list shr centric, so please post your "shr > rulz" stuff at the shr lists. Ok, so we can't talk about any distro here, cause it isn't "Android centric"? I can't recommend Debian for someone here, cause it's not "Debian centric"? Be serious! SHR has the best system to send new recipes. If something else would have better, then i'd talk now about that, not SHR. Again, don't make people idiots, cause in majority of cases person who does that shows that he's idiot himself! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 11:46 AM, Patryk Benderz wrote: >> ABSTRACT >> I think a new showroom for community created application is needed to > I think instead of creating new showroom it is better to improve > existing ones. >> boost the development and help users to get to know new apps easily. > Wiki does this (applications section) It does not look good! Wiki is a nice idea, freely editable for everyone - but it just doesn't work for all purposes. >> SETUP >> community, the comment system has alowed us to get in touch with the >> developer/packager and we've seen nice screeshots there to encourage >> us to try apps. Also the release of opkg.org repository was great! > Wiki does this all also. Can't get RSS out with comments. Wiki doesn't create a repository. And - it doesn't look appealing! > >> For Freerunner, we need something like this to do the trick. Being >> easily able to promote applications will inspire devels to write apps >> which the makes the users and other devels more satisfied with >> Freerunner and inspire more developers to participate. Repositories >> are nice but there needs to be a way for people to know what apps are >> now in. Ubuntu with ~30 000 packages doesn't inspire me to try even a > This is untrue my friend, first of all it would be not 30 000 but 27 > 000. But that is not true either because ~25100 of these packages are > backported from Debian. Thus the remeining ~1900 packages belong to > Ubuntu. Thanks for pointing these details out. My point was that a long list of apps and libraries mixed together is not an easy format to go and find the coolest apps. > Regardless of the above, we should not compare Ubuntu/Debian > repositories with opkg.org, simply because opkg is not repository. Not? See http://www.opkg.org/packages ... >> METHODS >> > [...cut] > Or if i didn't convinced you yet - > try to catch opkg author, and convince him to hand over opkg page to > community. Have tried to do that for ~6 months now. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> Maybe you don't know, but SHR is based on OpenEmbedded, so every > Openmoko OE based distro can benefit from bb files in SHR (and after > commiting our work to org.openembedded.dev not only Openmoko distros > will be able to use that). ok, i try again: not every distribution used on the fr is based on oe. was that easier to grasp? btw: i don't recall to be this list shr centric, so please post your "shr rulz" stuff at the shr lists. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Fri, Aug 21, 2009 at 10:44 AM, Michael Pilgermann wrote: > Dear all, > > maybe, another perspective here from an apps developer's point of view: > > I do believe, that we need a proper / nice directory of applications, which > users may browse through. I am aware of the following repositories right now: I agree. And I think that: - openmoko wiki CAN be used to create a showroom but it's hard to make it look nice. I mean nice, not just have screenshots. - opkg.org - looks like it's not possible to develop it and we need to start from scratch - openmoko projects (as well ass google code, launchpad etc) is a great platform to develope the projects but not share - as there are so many unfinished and unmaintained projects around. And again, it doesn't look nice nor is easy to use. -> good for devels, not users - community updates is just a newsletter. You can't go and tell someone to read all community updates from last 6 months to see what apps are around - SHR manual.. well, that's only for SHR, not a general solution for all distros so I'd exclude it from this discussion. -> Still I think there's a need for a platform to promote ~working apps in an appealing way. It's not supposed to be the 'all information about this app' page, just a showcase that'd link to actual homepage (be it google code wiki or openmoko wiki or gforce or whatever) with the manuals etc. > But I think, it is not a good plattform for people to browse projects. There > is a point of establishing something "inviting* here. However, I would > suggest the following points: > > * Make it a really simple, good-looking overview of applications to browse > through > * Keep Openmoko projects as development repository - do not duplicate stuff, > we have in there already (put links instead) > * Make it possible to easily install applications (simple instructions as > given in opkg.org - so we wouldn't need this plattform anymore) > * Do not maintain another list on openmoko wiki - instead put a link there to > this new directory > * Whenever you present information about a project (e.g. community newsletter > or user manuals) provide a link to the app inside this plattform instead of > detailling installation instructions (they might change from one version to > the next) > * Support community input (comments, maybe voting) > * Again: Make it beautiful and simple. You read my mind! > For the packaging issue - I really like the idea of boosting the process to > integrate into reps / distributions. (this would btw. ease the process of > installation). > However, documentation on how to do this is really rare. So true. This is something I'd hilight in the wiki and let all current app devels to know: how to create the required files to get your app to distros. But as also mentioned, it shouldn't be the devel who does this but someone else as package/distro maintainer. > I wouldn't spend too much time when bringing up a SHOWROOM on tricky, > technical stuff. Just a plain, simple, beautiful web site (supporting > categories and distributions is nice I think) and - at least for now - manual > installation instructions. > I think, every OM user is able to run 'opkg install '. It would be a > great step forward, if deps are resolved and so on +1! > Very last words: > Please do not put anything up, when there is no time / resources to maintain > it. It would be a shame to waste so much efforts +1! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, arne anka wrote: >> shr-de...@lists.shr-project.org >> This maillist has patchwork on top of it on >> http://patchwork.dev.bearstech.com/ >> I think that's enough. > > maybe you haven't heard yet -- but not everybody uses shr. > and since the subject clearly states ALL, i don't really see what makes > you so adamant about shr here. Maybe you don't know, but SHR is based on OpenEmbedded, so every Openmoko OE based distro can benefit from bb files in SHR (and after commiting our work to org.openembedded.dev not only Openmoko distros will be able to use that). So don't think you know everything. If I said that, then probably I had some reason. Don't make people idiots, please... -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> shr-de...@lists.shr-project.org > This maillist has patchwork on top of it on > http://patchwork.dev.bearstech.com/ > I think that's enough. maybe you haven't heard yet -- but not everybody uses shr. and since the subject clearly states ALL, i don't really see what makes you so adamant about shr here. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
> My opinion is simple. Developer of app provides bb file (or asks > someone to write it) and then all distros provide that app in repo. > And that's all. I agree, however after going through all the development pages in a wiki. The steps involved in creating an application and making a *.bb file for it, is not immediately evident to me. If all we need is for application developers to provide bb files. I think we need better documentation on the issue. Some wiki page explaining the relation between the tools, and some example bb files. I believe this will lower the barrier of getting applications into the repositories. Regards, Adolph ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Fabian Henze wrote: > On Thursday, 20th of August 2009 14:04:49 UTC Sebastian Krzyszkowiak wrote: >> My opinion is simple. Developer of app provides bb file (or asks >> someone to write it) and then all distros provide that app in repo. >> And that's all. > > That's a great idea. But there has to be some way for a distro maintainer to > get the latest bb files easily. Maybe a RSS feed, which contains all > projects? > > -- Fabian Henze shr-de...@lists.shr-project.org This maillist has patchwork on top of it on http://patchwork.dev.bearstech.com/ I think that's enough. -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On 8/21/09, Michael Pilgermann wrote: > For the packaging issue - I really like the idea of boosting the process to > integrate into reps / distributions. (this would btw. ease the process of > installation). > However, documentation on how to do this is really rare. One could probably > find a way to create a bb file (and also further required files) - but the > way on > > * how to get this into a rep. / distribtution? * > > is really not transparent. Whom do I need to contact? Do I have to file an > issue somewhere? The Openmoko wiki is not really helpful about this topic. It was discussed DOZENS of times on maillist. Sending bb recipe (or asking for writing such recipe) to shr-devel maillist is in majority enough to have your app in SHR and FSO repositiories, which is enough, as I don't know other active and supported OpenEmbedded based distro here which isn't based on SHR or Om2009. And if documentation isn't good enough: improve it, instead of making something wrong by design! > Lasts words: > I wouldn't spend too much time when bringing up a SHOWROOM on tricky, > technical stuff. Just a plain, simple, beautiful web site (supporting > categories and distributions is nice I think) and - at least for now - > manual installation instructions. > I think, every OM user is able to run 'opkg install '. It would be > a great step forward, if deps are resolved and so on ... Distribution repository, with graphical installer which can display screenshots and descriptions. Some work on that is started in shr-installer project. Nothing more is needed! -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Dnia 2009-08-20, czw o godzinie 16:46 +0300, Risto H. Kurppa pisze: > Hi there! > > ABSTRACT > I think a new showroom for community created application is needed to I think instead of creating new showroom it is better to improve existing ones. > boost the development and help users to get to know new apps easily. Wiki does this (applications section) > Now we have opkg.org to show & distribute the apps created by the > community for Freerunner. > > SETUP > opkg.org has allowed us to easily see what apps are new in the Go ahead and improve wiki to show new > community, the comment system has alowed us to get in touch with the > developer/packager and we've seen nice screeshots there to encourage > us to try apps. Also the release of opkg.org repository was great! Wiki does this all also. > > But: > opkg.org is has many outdated and broken packages with missing dependencies > opkg.org doesn't separate packages for different distributions > opkg.org doesn't share the source codes as per GPL > opkg.org code can be changed only by the main developer > opkg.org developer doesn't seem to be working on it any more (since April) > opkg.org developer is not an easy fish to catch > > Now have a look at these: sorry but i didn't even bother... [cut] > For Freerunner, we need something like this to do the trick. Being > easily able to promote applications will inspire devels to write apps > which the makes the users and other devels more satisfied with > Freerunner and inspire more developers to participate. Repositories > are nice but there needs to be a way for people to know what apps are > now in. Ubuntu with ~30 000 packages doesn't inspire me to try even a This is untrue my friend, first of all it would be not 30 000 but 27 000. But that is not true either because ~25100 of these packages are backported from Debian. Thus the remeining ~1900 packages belong to Ubuntu. Regardless of the above, we should not compare Ubuntu/Debian repositories with opkg.org, simply because opkg is not repository. > music player without comments from others and a screenshot. > > METHODS > [...cut] Everything in METHODS and below can be obtained with already existing wiki. As a conclusion: better use your spare time to improve wiki instead of creating another opkg.org. Or if i didn't convinced you yet - try to catch opkg author, and convince him to hand over opkg page to community. -- Kind Regards, Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
On Thursday, 20th of August 2009 14:04:49 UTC Sebastian Krzyszkowiak wrote: > My opinion is simple. Developer of app provides bb file (or asks > someone to write it) and then all distros provide that app in repo. > And that's all. That's a great idea. But there has to be some way for a distro maintainer to get the latest bb files easily. Maybe a RSS feed, which contains all projects? -- Fabian Henze ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
[cut] > My opinion is simple. Developer of app provides bb file (or asks > someone to write it) and then all distros provide that app in repo. > And that's all. +1 -- Kind Regards, Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ALL] New showroom for Openmoko apps
Dear all, maybe, another perspective here from an apps developer's point of view: I do believe, that we need a proper / nice directory of applications, which users may browse through. I am aware of the following repositories right now: - openmoko wiki - applications (I think, it is a good starting point if you look for something; but could be somehow more fashined - and up to date) - opkg.org - good for uploading (or linking) releases - though, I never used it as a repository (somehow I didn't feel it's a proper rep) - openmoko projects - from my view a good development plattform, which is doing the job (it is just not too fancy - but, come on, we are developers) - community updates - new: SHR manual (also telling me some bits and pieces about software) - *** did I forget something? probably I did *** So, when doing a release right now - I have to update 4 pages already (openmoko projects, opkg.org, community updates and SHR manual), because each of them comes with its own installation instructions (the wiki is rather static). What I want to point out first of all: * We do not need another plattform ON TOP of all this * We should rather go and integrate stuff. For me, openmoko projects server (gforge) is a very good starting point for that: * source code management (svn) * file releases * bug tracking, feature requests * news support * and WIKI functionality I think, we should really keep this as a basis. But I think, it is not a good plattform for people to browse projects. There is a point of establishing something "inviting* here. However, I would suggest the following points: * Make it a really simple, good-looking overview of applications to browse through * Keep Openmoko projects as development repository - do not duplicate stuff, we have in there already (put links instead) * Make it possible to easily install applications (simple instructions as given in opkg.org - so we wouldn't need this plattform anymore) * Do not maintain another list on openmoko wiki - instead put a link there to this new directory * Whenever you present information about a project (e.g. community newsletter or user manuals) provide a link to the app inside this plattform instead of detailling installation instructions (they might change from one version to the next) * Support community input (comments, maybe voting) * Again: Make it beautiful and simple. For the packaging issue - I really like the idea of boosting the process to integrate into reps / distributions. (this would btw. ease the process of installation). However, documentation on how to do this is really rare. One could probably find a way to create a bb file (and also further required files) - but the way on * how to get this into a rep. / distribtution? * is really not transparent. Whom do I need to contact? Do I have to file an issue somewhere? The Openmoko wiki is not really helpful about this topic. Lasts words: I wouldn't spend too much time when bringing up a SHOWROOM on tricky, technical stuff. Just a plain, simple, beautiful web site (supporting categories and distributions is nice I think) and - at least for now - manual installation instructions. I think, every OM user is able to run 'opkg install '. It would be a great step forward, if deps are resolved and so on ... Very last words: Please do not put anything up, when there is no time / resources to maintain it. It would be a shame to waste so much efforts Michael Original-Nachricht > Datum: Thu, 20 Aug 2009 16:04:49 +0200 > Von: Sebastian Krzyszkowiak > An: List for Openmoko community discussion > Betreff: Re: [ALL] New showroom for Openmoko apps > On 8/20/09, Risto H. Kurppa wrote: > > Hi there! > > > > ABSTRACT > > I think a new showroom for community created application is needed to > > boost the development and help users to get to know new apps easily. > > Now we have opkg.org to show & distribute the apps created by the > > community for Freerunner. > > > > SETUP > > opkg.org has allowed us to easily see what apps are new in the > > community, the comment system has alowed us to get in touch with the > > developer/packager and we've seen nice screeshots there to encourage > > us to try apps. Also the release of opkg.org repository was great! > > > > But: > > opkg.org is has many outdated and broken packages with missing > dependencies > > opkg.org doesn't separate packages for different distributions > > opkg.org doesn't share the source codes as per GPL > > opkg.org code can be changed only by the main developer > > opkg.org developer doesn't seem to be working on it any more (since > April) > > opkg.org developer is not an easy fish to catch > > > > Now have a look at these: > > http://www.apple.
Re: [ALL] New showroom for Openmoko apps
On 8/20/09, Risto H. Kurppa wrote: > Hi there! > > ABSTRACT > I think a new showroom for community created application is needed to > boost the development and help users to get to know new apps easily. > Now we have opkg.org to show & distribute the apps created by the > community for Freerunner. > > SETUP > opkg.org has allowed us to easily see what apps are new in the > community, the comment system has alowed us to get in touch with the > developer/packager and we've seen nice screeshots there to encourage > us to try apps. Also the release of opkg.org repository was great! > > But: > opkg.org is has many outdated and broken packages with missing dependencies > opkg.org doesn't separate packages for different distributions > opkg.org doesn't share the source codes as per GPL > opkg.org code can be changed only by the main developer > opkg.org developer doesn't seem to be working on it any more (since April) > opkg.org developer is not an easy fish to catch > > Now have a look at these: > http://www.apple.com/iphone/iphone-3gs/app-store.html > http://www.android.com/market/ > https://store.ovi.com/?lid=storeherotxt&cid=ovistore-fw-ilc-body-acq-na-ovicom-g0-na-2&lang=fi-FI > http://getdeb.net/ > http://maemo.org/downloads/OS2008/ > > They all > a) show a screenshot > b) allow a more or less easy installation of the selected app > > For Freerunner, we need something like this to do the trick. Being > easily able to promote applications will inspire devels to write apps > which the makes the users and other devels more satisfied with > Freerunner and inspire more developers to participate. Repositories > are nice but there needs to be a way for people to know what apps are > now in. Ubuntu with ~30 000 packages doesn't inspire me to try even a > music player without comments from others and a screenshot. > > METHODS > > Landing to the site would let you select your preferred distribution. > SHR, OM2009, Debian, OpenWRT, ..? - possibly include also > stable/testing/unstable versions. After this you would only see the > apps that have been marked as tested on that distribution. > > Installation would be done from a repository - the best would be to > use the ~official repositories for each distribution (openembedded, > openmoko, shr, fso-pkg/deb etc) OR we build a new repository only for > apps presented in the showroom, a different one for each distribution. > And if there is a repository, also the source code needs to be there > (GPL..) > > Then next level would be to create a gui for Freerunner to show the > screenshots and allow easy installation, something like apturl. Maybe > this functionality could be built on top of one of the existing > graphical package managers? > > And last but not least, allow more people than only one to have access > on the site code.. > > I'm sure there are some people in the community who feel like doing > something to support the community but don't have the skills to hack > the kernel: this is an opportunity for all PHP/Django/Web gurus to > contribute. > > Does anyone know if software enabling this exists? Could eg. Launchpad be > used? > > DISCUSSION > > There's nothing new here: all this was suggested already 10 months ago > when opkg.org was announced, see > http://lists.openmoko.org/pipermail/community/2008-October/thread.html#33132 > > Separation for each distribution is naturally required: all packages > created for SHR just won't work on OM2009 as the lib versions are not > the same etc, and then we have the debian-based distributions too and > so on.. > > Problem with packages in opkg.org and packages in random websites (as > well as some packages in the repositories) is that if they use lib X > and lib X version is updated, the app Y stops working without the > author/maintainer knowing about it until weeks later, or maybe the > kernel paths change again. So next time they decide to include the > whole lib X in their app just to be sure it doesn't happen again. The > lack of coordination and communication results broken and/or bloated > software. > > So I'd prefer using the existing/official repositories and try to find > maintainers, not start a new fragmented repository for each > distribution > > We need package maintainers who make sure a new nice community-written > app will be added to the official repositories of distributions, I > think it's not good to expect the author can create packages for say 5 > distributions. > > CONCLUSION > > What do you think? My opinion is simple. Developer of app provides bb file (or asks someone to write it) and then all distros provide that app in repo. And that's all. That's distro maintainers who should do packages, not app developers! When app developers do packaging, then resulting pkgs are outdated and unusable after some not-so-long time. When it's added into distribution build system, then the only problem can be compilation error. That's why I think there is no need for pages like opkg.org, eventually for very s
[ALL] New showroom for Openmoko apps
Hi there! ABSTRACT I think a new showroom for community created application is needed to boost the development and help users to get to know new apps easily. Now we have opkg.org to show & distribute the apps created by the community for Freerunner. SETUP opkg.org has allowed us to easily see what apps are new in the community, the comment system has alowed us to get in touch with the developer/packager and we've seen nice screeshots there to encourage us to try apps. Also the release of opkg.org repository was great! But: opkg.org is has many outdated and broken packages with missing dependencies opkg.org doesn't separate packages for different distributions opkg.org doesn't share the source codes as per GPL opkg.org code can be changed only by the main developer opkg.org developer doesn't seem to be working on it any more (since April) opkg.org developer is not an easy fish to catch Now have a look at these: http://www.apple.com/iphone/iphone-3gs/app-store.html http://www.android.com/market/ https://store.ovi.com/?lid=storeherotxt&cid=ovistore-fw-ilc-body-acq-na-ovicom-g0-na-2&lang=fi-FI http://getdeb.net/ http://maemo.org/downloads/OS2008/ They all a) show a screenshot b) allow a more or less easy installation of the selected app For Freerunner, we need something like this to do the trick. Being easily able to promote applications will inspire devels to write apps which the makes the users and other devels more satisfied with Freerunner and inspire more developers to participate. Repositories are nice but there needs to be a way for people to know what apps are now in. Ubuntu with ~30 000 packages doesn't inspire me to try even a music player without comments from others and a screenshot. METHODS Landing to the site would let you select your preferred distribution. SHR, OM2009, Debian, OpenWRT, ..? - possibly include also stable/testing/unstable versions. After this you would only see the apps that have been marked as tested on that distribution. Installation would be done from a repository - the best would be to use the ~official repositories for each distribution (openembedded, openmoko, shr, fso-pkg/deb etc) OR we build a new repository only for apps presented in the showroom, a different one for each distribution. And if there is a repository, also the source code needs to be there (GPL..) Then next level would be to create a gui for Freerunner to show the screenshots and allow easy installation, something like apturl. Maybe this functionality could be built on top of one of the existing graphical package managers? And last but not least, allow more people than only one to have access on the site code.. I'm sure there are some people in the community who feel like doing something to support the community but don't have the skills to hack the kernel: this is an opportunity for all PHP/Django/Web gurus to contribute. Does anyone know if software enabling this exists? Could eg. Launchpad be used? DISCUSSION There's nothing new here: all this was suggested already 10 months ago when opkg.org was announced, see http://lists.openmoko.org/pipermail/community/2008-October/thread.html#33132 Separation for each distribution is naturally required: all packages created for SHR just won't work on OM2009 as the lib versions are not the same etc, and then we have the debian-based distributions too and so on.. Problem with packages in opkg.org and packages in random websites (as well as some packages in the repositories) is that if they use lib X and lib X version is updated, the app Y stops working without the author/maintainer knowing about it until weeks later, or maybe the kernel paths change again. So next time they decide to include the whole lib X in their app just to be sure it doesn't happen again. The lack of coordination and communication results broken and/or bloated software. So I'd prefer using the existing/official repositories and try to find maintainers, not start a new fragmented repository for each distribution We need package maintainers who make sure a new nice community-written app will be added to the official repositories of distributions, I think it's not good to expect the author can create packages for say 5 distributions. CONCLUSION What do you think? r ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
