Thanks for the remove of the debian-dir.
I setup a daily build for ubuntu natty now (for maverick and lucid i don't
know how to do because of unmet dependency for libsynthesis).
The git-source will be synced to launchpad (i think daily) and then a debian
package will be created with the source and the package will be available in
automatically cynced source in launchpad:
2011/1/7 Patrick Ohly <patrick.ohly(a)intel.com>
On Do, 2011-01-06 at 20:23 +0000, Ove Kaaven wrote:
> Den 06. jan. 2011 18:56, skrev Patrick Ohly:
> > On Do, 2011-01-06 at 17:42 +0000, toabctl wrote:
> >> Any reasons why the debian-dir should exist?
> > Ove Kaaven is using it for the Maemo 5 port. As he is also contributing
> > code, so it makes sense to do change tracking of everything in one
> > place.
> > But I suppose we could rename the dir to "debian-maemo5", with a
> > "debian" symlink set manually by Ove when needed. Ove, does that
> Actually I'd be fine with removing it from the upstream source.
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jan 7 09:29:31 2011 +0100
packaging: removed obsolete "debian" directory
The reason for removing it is that it breaks the daily build in
Launchpad (see "[SyncEvolution] remove debian/ dir from source").
It wasn't used anymore except in Ove's branch for Maemo 5. Should the
files be needed again in git, then the directory should be renamed.
> debian/ dir used in the Maemo5 packages is modified quite a bit, and
> those changes were never (actively) merged back upstream (they're too
> platform-specific for that to make much sense). So it would not have any
> negative consequences for me - I've maintained my own debian/ in my own
> git so far, and I'd just continue to do so.
That reminds me: do you publish your git repo somewhere? It would make
sense to merge back your changes into the main repo at least once in a
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.