Please do not include debian/ in your source tree

In my opinion in his previous post Robert Collins proposes a change which does not help packaging, instead it would just make things worse.

DO NOT include a packaging debian/ directory into your source tree. If for whatever reason you need to provide your application out of the official repositories just upload to a PPA using the regular process with the source+debian diff .

Including the debian directory on your source does not help anyone, however it will make life's harder for people that wants to package your software. The debian/* format is standard but it's implementation, integration and component versions between different distributions and releases are not.
There are plenty of reasons for projects/individuals to provide your software built/integrated in a different manner. Including a specific version of a package building process on the source will conflict with the regular packaging process, source+buldif diff forcing other packages to change your source by removing the /debian dir or maintaining a diff for it.

I agree with Robert that upstreams should be more involved with distros and whenever possible take care of the packaging, the blockers for that are more social than technical. If there is an understanding that the "introduce a new package" process is not acceptable/friendly with upstreams then it should be improved.

If the objective was to improve packaging collaboration then just move debian/* to a VCS, that way everyone can collaborate: upstream, distribution maintainers and 3rd parties.

RSS feeds available for GetDeb package updates

Last week I have changed the package updates links organization, cleaned up the main updates fetching/filtering code and finally added the most frequently requested feature: RSS feeds.

With the new organization updates are available from the following links:
http://www.getdeb.net/updates/Ubuntu/$release/
Where $release = 9.04, 9.10.. or all to show updates for all releases.

The application specific pages are now http://www.getdeb.net/software/appname, right now they just provide the same info from /updates/, comments, ratings, etc will go into the /software/ section.

Let's fix bug #1 without regressions

Linux usability on the Desktop OS has significantly increased, this brings two major problems:
1) Wider range of hardware and use cases, increasing the chances of problems with untested use scenarios,
2) Linux on the Desktop is moving from an hobby OS to a main workstation OS, regressions have a serious impact, they now affect some business or some people work

Ubuntu and Desktop distros in general are trying to resolve problem 1 by pushing new technology as faster as they can, but what about problem 2 ? Is it really being addressed ?

Some years ago the FAQ was "I have tried Ubuntu on my PC and there is no sound, no network and my device Y is not recognized", most of the times the root cause and answer was simple: "The current kernel drivers do not support your hardware yet" or "You need additional configuration to enable the driver" - additional work needs to be done, someone needs to improved/develop drivers and/or configuration tools.
These days, the FAQ is "My sound, network and graphics where working great until I did an upgrade", the answer "It's a regression" is not that easy to explain - work was done on some driver/configuration in order to improve it and it's failing on your case, possible reasons are: unknown problem(not tested), known (waiting for a fix), known (won't fix).

I hope we are not running in competition for hardware/features/whatever support with the leading OS.
The fix for bug #1 should not introduce such a severe regression as lack of reliability.

Forget the Koala fight and let's go Lynx

There is a lof of debate whether Karmic Koala was a good or bad release, that is all a matter of expectations. In my opinion, we, the Ubuntu community did a great job but the outcome was not as good as some people expected.

I have read the following reply from Martin Pitt on the ubuntu-devel-discuss which makes me believe this was an accounted risked, part of the preparation for a much important goal which is 10.04 LTS:

" Well, the bug tracker is full of regression and other reports. Karmic
indeed was meant from the start as a "crack dump" release, with lots
and lots of new technology going into it. So in a way, it was the
Fedora of Ubuntu releases so far.

Perhaps we should have announced that more clearly...

At least we now have a full cycle ahead of us to do bug fixing. :) "

Unlike the usual blame game this was a much simpler and probably more realistic answer.

Instead of wasting energy debating if it really failed let's just try to fix it. Sometimes is not a technically failure and it is just lack of understanding on how things work, if that is the case we still need to fix it, it's a matter of improving awareness and communication.

GetDeb v2 Beta Available

GetDeb v2 Beta is a major milestone on the GetDeb project development, it addresses most of the technical limitations of the current system/engine that we have been using for the last 3 years.
The major improvements are:

* Software installation using a GPG signed APT repository with mirror distribution
* Single click installation even for multi-package installs
* Automatic software updates (from the repository)
* New design - for the first time not based on a Ubuntu offical site
* Web based applications publishing


These changes will increase our ability to provide more and better packages in a safely manner.
Most of the effort was invested at the APT-Portal project, which is shared with Playdeb and because is open source it can be used by by other teams to deploy their own repository based portals.

Both the design and code base -rewritten in python- still need a lot of work, if you have any skills with Python/HTML/CSS/AJAX please join the developers team.

http://beta.getdeb.net
http://wiki.getdeb.net/apt-portal

Importing APT repository info into a SQL DB

Hello,
in case you love repositories and databases there is a simple utility that allows you to export a remote APT repository metatada into a SQL database.
It was only tested with sqlite3 and MySQL, should work with any sqlalchemy supported DB .

First you need to get debfactory using bzr:

bzr checkout lp:debfactory

Now let's import the package info for Ubuntu Karmic (i386).

cd debfactory/bin
./apt2sql.py -d sqlite:///apt2sql.db \
http://archive.ubuntu.com/ubuntu/ karmic "*" i386

Check the packages count from the db:

sqlite3 apt2sql.db "SELECT COUNT(*) FROM package"