maemo.org/downloads automatic updates from Extras

The maemo.org downloads section now automatically picks up updated versions from the Maemo Extras repository. The 'Fresh' list will show the applications that were recently uploaded or promoted to Extras. Developers used to need to update their application entry themselves. By doing the updating automatically, users should not see outdated information about applications.

For the automatic update to work your application needs to be:

1. Available in Maemo Extras
2. Available in the maemo.org downloads section where the 'Project ID' equals the name of your debian package.

Package updates are fetched from the most recent repository for each OS we support. Diablo for OS2008, Bora for OS2007 and gregale for OS2006.

One enhancement I would like to add is automatically update the 'Changes in latest version' field for the entry in downloads. I would like comments from the community on how developers should supply this information.

One option would be to fetch it from the changelog. Problems here are that there aren't many packages using a changelog at the moment and we would need to filter out the real changes from the packaging revision updates.

Another option would be to let the developer enter this data while promoting the package to extras. We could add this step to the promotion interface.

Comments are appreciated.

Application in Extras-Devel OK? Promote it!

Now that we have the autobuilder in place for Diablo, it is a good time to talk about how to get your package from Extras-Devel into the Maemo Extras repository.

Before a package will end up in Extras and is installable for end-users on their device, it will go through a few steps:

1. source package uploaded to autobuilder incoming queue
2. autobuilder builds package and moves it into the incoming queue from Extras-Devel
3. queuemanager for Extras-Devel will put the package in the Extras-Devel repository
4. developer checks packages from Extras-Devel and if the package is OK:
5. promote the package to Extras using the Promoter.

Step 5 is the step where you can use the Promoter to promote your package. Make sure you test your application while it is in Extras-Devel, so you don't promote a broken package. After promotion and a bit of patience, your package will show up in Extras and everybody will be able to download it.

We have two Promoters is place:

• Diablo Promoter
• Chinook Promoter
  

The Promoter is a community project on garage.maemo.org. The code can be found in the svn repository. If you have any suggestions on how to improve the interface or would like to add functionality, please propose and discuss it on the maemo-developers mailinglist.

We are still working on documenting Extras and Uploading to extras in the wiki and of course work towards The Big Plan. Feel free to edit the wiki and improve the articles, this is a community project.

Let's work together to get more applications available in Maemo Extras!

Rebuild all chinook source packages on autobuilder

Currently Ed Bartosh and I are working on taking all source packages from the extras repository and try to build them on the autobuilder. The goal of this chinook rebuild effort is to get a set of packages buildable 'from scratch'.

Once we are able to build all(most?) packages on chinook, we can try to automatically build them for diablo. So we can have a lot of packages in the diablo repository at release of diablo.

There is a web page up with the first run, which was done over the weekend. All packages are listed in build order, based on dependencies, with their build results for i386 and armel. If a package build failed, a link to the build log is provided.

If you provide a source package in extras, please check if your package is building OK. If you only provide binary packages in extras, we would like to encourage you to provide source packages too! We could really use some help from the community in pushing towards 100% OK build of every package in extras.

When you have updated your package to fix the issues, please use the 'request rebuild' option on the packages list. This gives us the opportunity to track changes as a result of the list. We will rebuild packages on a regular interval and post a summary to maemo-developers. Let's see if we can get all packages to build!

Autobuilder for maemo extras repository part 2

Some time has passed since we first announced the maemo autobuilder for the extras repositories. Some people have tested it and we got a little bit of feedback. Not as much as we hoped, but I'm sure that is going to get better shortly.

Ed has been working on making the autobuilder more user-friendly. You will now receive a status message per mail when your package has been processed. If there were any errors (md5 sum failed, files missing, wrong pgp key or package not signed), you will find that out in the email.

Some benefits of using the maemo autobuilder:

• Source packages always available in the repository
• i386 packages are automatically added to the repository, so you can use them in the SDK.
• Prevent obviously broken packages from entering the repositories.
  

I have been improving the assistant by adding more checking and fixing more bugs. It turned out that not everybody was able to request rights to upload packages to the repository. Sorry about that!

I would like to ask all developers to try out the autobuilder and assistant, so we can be in a good shape before Diablo gets released. We can only move forward if you get involved!

Feel free to contact me if you need any help or information.

maemo packaging policy draft

A draft for the maemo packaging policy has been released for comments by the community.

What is the maemo packaging policy good for?

Like it's Debian counter part, the maemo policy specifies how packages should be built. It will exactly tell you what your package should implement to be a proper maemo package.

The maemo packaging policy is essentially the same as the Debian policy, but there are some changes especially for the tablets as opposed to desktops.

What good does it do me?

Well, not a lot at the moment. But it can soon! We (the maemo community) need to agree on this policy and see how we can implement it.

We want to setup a wiki page where you can annotate the policy draft and talk about things you think should change. This will be done soon, I hope.

Until then, please discuss the topic on the maemo-developers list.

Your input is welcomed.

Autobuilder for extras repository public beta

A while ago we discussed the idea of an autobuilder for the extras repository. We have been working on creating such an autobuilder and have been testing it in private. As a result we now think it is time to do a tests with a larger group and make it publicly known. Please give it a try and tell us your results.

- What does the autobuilder do?

The autobuilder takes a source package from the incoming queue and tries to build it in a fresh environment. The builder fetches all dependencies from the extras-devel repository. If it can't find the dependency in extras-devel, it will fail and send a mail to the extras-cauldron-builds list.

If there are no problems with the package, the builder can create armel, i386 and source packages. Those will be put in the extras-devel repository after a successful build.

Instructions for the builder can be found at here.

The builder only handles building one package at a time. If you have dependencies that are not present in the extras-devel repository, please upload these first.

- web-based assistant

We have also created a web-based assistant to help you with requesting rights to upload and creating/uploading of source packages. You can upload packages to the builder with either dput or the assistant.

- How do I get my package into extras?

After a successful build a package will appear in the extras-devel repository. You can move your packages from extras-devel to extras with the promotion interface. Instructions for the promotion interface can be found here.

We would like to invite all developers to take a look at the autobuilder and try it out. Please discuss problems and feature requests on the maemo-developers list.

More information about our effort can be found at the extras-cauldron website.

[RFC] Maemo package guidelines: mandatory categories

Here is my first suggestion to clean up the complete mess we have at the moment when it comes to package categories in the maemo extras repository. There is no official list of categories, which has brought us to state we are in now.

We have these nice categories for example: 'Boingo', 'Canola'. Those should never be a category by themselves. We also have a lot of duplicates like 'cli' ,'Commandline' and 'Web','www' and 'Utilities','utils'.

This really has to stop as this is confusing for end users. We, the maemo community, need to find a solution and fix this.

If we look at Debian, we can see that they have the following list of categories:

admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11

My suggestion would be to base our list off the Debian list and remove the categories that are not suitable for Maemo. We might also want to add some categories if we find some missing.

admin, comm, devel, doc, editors, games, graphics, interpreters, mail, net, news, utils

and add:

desktop, database, education, internet, multimedia, office, scientific, security, system, travel

Please feel free to suggest other categories. Try to keep them as broad as possible. I would really like to get a list of categories where every application can be in at least one category. It would be nice not to need the 'misc' or 'other' category.

Perhaps it would also be a good idea to have the Application Manager display the pretty name for each category. e.g. comm -> Communication. That might be step 2 though.

I also would like your feedback on this idea:
"For diablo we only accept packages in the extras/extras-devel repositories when they have a valid category."

I'm really not sure if we can do this in time for diablo, but at least we can try to get the community to agree on this. I don't think we can do anything for existing repositories, but at least we could try for the new ones.

Please respond with your ideas in the comments section, but keep it to the category subject only.

Edit:

There seems to be a list of categories for the Application Manager. I don't think that list has enough categories, but it is a start.