Happy New Year everybody! Wow it has been a long time since I blogged :)
A new year and we got new things to announce. We have been working on apps.formeego.org for a while. The idea is to have a community driven Apps catalog for open source applications. Created by the people who also contributed to maemo.org Downloads (More than 100M downloads and counting!), many of the concepts born there were brought along.
This site includes a community driven QA part, where you can test apps and fill in a simple score card about the app. Once a certain amount of positive reports have been made, the app will automatically go to the stable Apps site. Apps will also go through some automated tests, so we can prevent broken applications from entering the repositories.
With the N9 device now in the market, the community needs a central place to publish their applications. If your application needs special security capabilities, like sending text messages etc, you need to publish your application in a place that is 'trusted' by the device. Nokia has now granted Apps the same credentials as Nokia Store. This means that we can now let the community publish applications which need more than the default credentials.
We have a very nice Apps client for use on your N9. This makes it very easy to browse through the available apps and install them on your N9.
Most of the infrastructure and processes are in place, what we need now is help from you! Whether you are a developer (submit your app) or an enthusiast (help us test new apps), there is always a way you can help making it more attractive to end users. Make sure we are getting more new applications more quickly available for everybody!
The current setup of Apps for MeeGo is so that you can't have any external dependencies for your application, other than what is provided in the SDK and the Nokia Apps repository. I'll post a proposal on the wiki about how to allow these dependencies while trying to prevent a mess :)
A last thing to add: We see that MeeGo.com is going away at some point and we have a maemo.org heritage, so we are planning to move our authentication, OBS and wiki to maemo.org in the coming months.
Wednesday, January 4, 2012
Wednesday, February 24, 2010
Maemo 5 Extras reaches 3.5M downloads
The maemo.org Extras repository for community contributed software has reached 3.5 million downloads for Maemo 5. Software is offered through maemo.org free of charge and the repository is open to all developers. maemo.org Downloads is the web interface to the software available through maemo.org Extras.
We see the number of downloads grow every day. This makes the maemo.org Extras repository a great place for developers to get their software in the hands of end users. If you are interested in publishing your software through maemo.org, please visit the wiki.
We introduced improved download statics to show developers exactly how many downloads they received. The FM Radio Player application has received over 138000 downloads. FM Radio stats below:
The Extras repository has only been enabled on N900 devices by default in a recent software update. Before this update users needed to manually activate the repository in their Application Manager's catalog list. Also keep in mind that the Application Manager is not very easy to find, because of it being put in the 'More' menu.
Overall I think the number is quite impressive as these devices aren't available for a long time and a lot of people had problems even finding a device in their country.
Friday, January 29, 2010
Extras dput and promotion changes
With the change to the new server infrastructure, we also changed the way developers can use dput to upload their source packages to the autobuilder. We created a special host named drop.maemo.org for uploads using dput (and scp). The uploading to Extras wiki page has been updated with the correct information. Short story: replace garage.maemo.org with drop.maemo.org and continue like before.
Another change we had to make was how packages are promoted from diablo Extras-devel to Extras. The old promoter was no longer suitable for the current setup and needed to go. Promotion now works the same way as it works for fremantle Extras-devel to Extras-testing (direct promotion). The package interface for diablo Extras-devel can be found here.
There are still a few features missing for the diablo part of the packages interface, but promotion should work. I'll add build logs and context sensitive searches at a later point.
Another change we had to make was how packages are promoted from diablo Extras-devel to Extras. The old promoter was no longer suitable for the current setup and needed to go. Promotion now works the same way as it works for fremantle Extras-devel to Extras-testing (direct promotion). The package interface for diablo Extras-devel can be found here.
There are still a few features missing for the diablo part of the packages interface, but promotion should work. I'll add build logs and context sensitive searches at a later point.
Monday, January 18, 2010
Backwards compatibility broken PR1.1 SDK
I've been discussing this issue with some people before as hypothetical case, but now it seems that we run into it: Compiling and application against the PR1.1 SDK creates packages which can not be installed on earlier firmware releases.
In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem.
The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available.
For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented.
How can we work around this problem:
1: Only compile against the original SDK.
This prevents new features from ever be available to developers, but should work until there is real API/ABI breakage in a new firmware.
2: Use version specific repositories
This needs Application Manager support as we need to fetch from a separate repository every time. Also requires us to build against every sdk version known to man.
3: Depend on >= mp-fremantle-generic-pr | maemo-version
We would need a hack in the autobuilder to add depends to pr and maemo version. This way a user needs to upgrade to at least the required firmware image. I think this will make it easier for an end-user to understand what is happening.
We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description.
Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time.
If you have an alternative solution on how to go about fixing this
issue, then please let me know.
Discussions on the maemo-developers list or talk.
In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem.
The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available.
For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented.
How can we work around this problem:
1: Only compile against the original SDK.
This prevents new features from ever be available to developers, but should work until there is real API/ABI breakage in a new firmware.
2: Use version specific repositories
This needs Application Manager support as we need to fetch from a separate repository every time. Also requires us to build against every sdk version known to man.
3: Depend on >= mp-fremantle-generic-pr | maemo-version
We would need a hack in the autobuilder to add depends to pr and maemo version. This way a user needs to upgrade to at least the required firmware image. I think this will make it easier for an end-user to understand what is happening.
We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description.
Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time.
If you have an alternative solution on how to go about fixing this
issue, then please let me know.
Discussions on the maemo-developers list or talk.
Wednesday, October 7, 2009
Maemo 5 Downloads now available
For Maemo 5 applications which managed to reach the Extras repository through the community QA testing queue, maemo.org Downloads now has a home.
The Download catalog automatically imports all information for applications in Fremantle Extras. The only thing you need to add is a nice screenshot. (Or more if you want.)
There are quite some applications in the QA testing queue which are almost ready for promotion to Extras. We should see more entries after the Summit.
If you are coming to the Maemo Summit in Amsterdam, see you there!
Thursday, August 27, 2009
Proposal: XSBC-Bugtracker in debian package
While implementing the maemo.org packages interface, I wanted to add a link to the bugtracker for a package or project. Eventually integrating bug reporting/searching, but more on that later. As all information is gathered from the debian packages themselves, it would make sense to have the bugtracker URL available in the control file.
There doesn't seem to be a default field in debian control files for and URL of the bugtracker which the project is using. Therefor I want to propose introducing the XSBC-Bugtracker field.
XSBC-Bugtracker:
The URL of the bugtracker for this package, preferably (when applicable) the URL where you can directly file a bug. The content of this field is a simple URL without any surrounding characters such as <>.
Example:
XSBC-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=Wormux
By putting the bugtracker URL inside the package, people always have a way to find out where to file bugs. This could even be used for filing bugs through an application interface or crash reporter in the future.
When this feature is accepted, it should be added to the Packaging Policy too.
Please let me know what you think. Discussion at talk.maemo.org.
There doesn't seem to be a default field in debian control files for and URL of the bugtracker which the project is using. Therefor I want to propose introducing the XSBC-Bugtracker field.
XSBC-Bugtracker:
The URL of the bugtracker for this package, preferably (when applicable) the URL where you can directly file a bug. The content of this field is a simple URL without any surrounding characters such as <>.
Example:
XSBC-Bugtracker: https://bugs.maemo.org/enter_bug.cgi?product=Wormux
By putting the bugtracker URL inside the package, people always have a way to find out where to file bugs. This could even be used for filing bugs through an application interface or crash reporter in the future.
When this feature is accepted, it should be added to the Packaging Policy too.
Please let me know what you think. Discussion at talk.maemo.org.
Wednesday, July 29, 2009
Fremantle maemo-select-menu-location change
While working on the maemo.org package interface, I noticed that quite a few package's developers didn't notice the changes in Fremantle regarding maemo-select-menu-location.
Fremantle changes the way applications are visible in the menu. There are no sub menus like "Extra" or "Utility" anymore. All installed 3rd party software will be visible under "Applications" by default.
This means that maemo-select-menu-location is obsolete and has been removed from the SDK. More info about the removal can be found in this bug.
There are currently about 60 package instances in Fremantle Extras-devel that depend or pre-depend on this obsolete package. These packages can not be promoted to Extras-testing until their author updates the package.
Daniel has started working on a Porting to Fremantle QA wiki page, which should point out some changes needed when porting to Fremantle. I hope this will help developers with the problems they encounter for now.
Fremantle changes the way applications are visible in the menu. There are no sub menus like "Extra" or "Utility" anymore. All installed 3rd party software will be visible under "Applications" by default.
This means that maemo-select-menu-location is obsolete and has been removed from the SDK. More info about the removal can be found in this bug.
There are currently about 60 package instances in Fremantle Extras-devel that depend or pre-depend on this obsolete package. These packages can not be promoted to Extras-testing until their author updates the package.
Daniel has started working on a Porting to Fremantle QA wiki page, which should point out some changes needed when porting to Fremantle. I hope this will help developers with the problems they encounter for now.
Subscribe to:
Posts (Atom)