The source package should build on all supported releases

For reviewers: I've uploaded the source packages for the various target releases to my PPA:

https://launchpad.net/~free.ekanayaka/+archive/ppa

The various source packages are the same as in this branch, modulo debian/changelog.

I'm pointing our linode machines to that PPA repository so we can start using these packages "for real".

I'm getting upgrade errors in Dapper and Hardy.

Dapper:
[unpack] python-smartpm_1.2-3~3.6.06
[unpack] landscape-common_1.3.2~bzr137-0ubuntu0.6.06
(Reading database ... 31528 files and directories currently installed.)
Unpacking python-smartpm (from .../python-smartpm_1.2-3~3.6.06_i386.deb) ...
dpkg: error processing /var/lib/smart/packages/python-smartpm_1.2-3~3.6.06_i386.deb (--unpack):
 trying to overwrite `/usr/lib/python2.4/site-packages/smart/progress.py', which is also in package smartpm-core
Preparing to replace landscape-common 1.3.2~bzr137-0ubuntu0.6.06 (using .../landscape-common_1.3.2~bzr137-0ubuntu0.6.06_all.deb) ...
Unpacking replacement landscape-common ...
Errors were encountered while processing:
 /var/lib/smart/packages/python-smartpm_1.2-3~3.6.06_i386.deb
ERROR: Sub-process dpkg returned an error code (1)

root@ls4-dapper:~# dpkg -l|grep smartpm
ii smartpm-core 1.2-0ubuntu0.6.06 An alternative package manager that works wi
root@ls4-dapper:~#

Hardy:
[unpack] python-smartpm_1.2-3~0.CAT.8.04
(Reading database ... 20367 files and directories currently installed.)
Preparing to replace python-smartpm 1.2-3~0.CAT.8.04 (using .../python-smartpm_1.2-3~0.CAT.8.04_i386.deb) ...
Unpacking replacement python-smartpm ...

[config] python-smartpm_1.2-3~0.CAT.8.04
Setting up python-smartpm (1.2-3~0.CAT.8.04) ...
pycentral: pycentral pkginstall: not overwriting local files
pycentral pkginstall: not overwriting local files
dpkg: error processing python-smartpm (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 python-smartpm
ERROR: Sub-process dpkg returned an error code (1)

root@ls5-hardy:~# dpkg -l|grep smartpm
iF python-smartpm 1.2-3~0.CAT.8.04 Python library of the Smart Package Manager
ii smartpm-core 1.1.1~bzr20081010-0ubuntu0.8.04 An alternative package manager that works wi
root@ls5-hardy:~#

The activity is https://ls2.labix.org/account/standalone/computers/activity/45 (I just invited you for this account).

Thanks for tests!

So, in both cases the failure was due to some missing Conflicts
clauses in the new python-smartpm package, which didn't upgrade the
former non-split smartpm-core package correctly.

I've fixed this and re-uploaded the smartpm packages to my PPA, and
issuing an upgrade from Landscape was fine on both machines this
time. The landscape-client packages are still the same, so no changes
to this branch.

A small note for Andreas, ls4-dapper had smartpm-core version
1.2-0ubuntu0.6.06 installed, where does it come from? Apparently it's
not in the official Ubuntu repo and not even in

http://landscape.canonical.com/packages/dapper

So now the new packages are in place and ready for further testing.

In distros <= hardy, the cron job that needs to be removed has another name: it's /etc/cron.hourly/smartpm-core

Thanks Andreas, the postinst now removes the other old cron job too.

Free, this is a fantastic branch, thanks so much for working on it!

I'm curious about the debian/changelog situation. At the sprint we discussed a system of branches for managing the different changelogs (and version numbers) for each release. I notice that the changelog in this branch is now based on the jaunty one. Are you planning on implementing that system of branches? I'm just wondering where we'll go from now.

[1] Man, I didn't know you could break Depends onto multiple lines! that makes it a lot easier to read :-)

[2] I'm not sure why you did this dependency the way you did it:

+ update-motd | lsb-base (<< 3.2-14ubuntu2),

don't we always want lsb-base? If we have update-motd, won't that mean we won't get lsb-base? Maybe we should "Recommend" update-motd (which means it gets installed by default) and then in the postinst script deal with the case where update-motd isn't actually installed.

[3]
+ python-smartpm | smartpm-core (>= 1.1),

I think we should be able to get rid of the conditional here once we actually include smartpm 1.1 in our <= hardy repositories, right?

Thanks again!

I have the same questions/comments as Chris's #2 and #3. I'm super
happy to see the package get un-AutoPPA-ified, too! Thanks. I
haven't tested building or installing the updated packages, but
based on reading the changes, I'm +1 on the branch.

Actually, I have a question. I understand that the changes you've
made make it so that we can use the same source to build the package
for any Ubuntu release we want, but we need to provide a
release-specific changelog entry for each one. Are you planning to
automate that? Automating that part of the build process is a
significant part of the value AutoPPA provides.

I wonder if we can get by with just having something like debian/changelog.<release>, instead of a different branch for each Ubuntu release. debian/changelog could just be the current release, and when we want to build a package for older Ubuntu releases, we'd replace the changelog with the appropriate file. We could automate this easily and it wouldn't require us to maintain so many branches.

Thanks Jamu! For the record the packages are available in my PPA:

https://launchpad.net/~free.ekanayaka/+archive/ppa

they all build from the same source (modulo debian/changelog) and
they've been tested to upgrade ls4-dapper and ls5-hardy (via
Landscape), which are now running them.

There is still one pending client issue (Bug #388092) to solve, but on
the packaging side it seems we're done. I hope we can fix it today and
then build a kind of release candidate for all us to test.

So yes, as Jamu points out, debian/changelog is the only file which
will differ across the different source packages. The picture I have
in mind would be:

1) The debian/changelog in trunk is targeted to the current Ubuntu
development version, for example till we don't release the final 1.3.2
the last entry should be:

landscape-client (1.3.2-0ubuntu1) UNRELEASED; urgency=low

and as soon as we release, we commit, tag and upload to karmic as:

landscape-client (1.3.2-0ubuntu1) karmic; urgency=low

This would be the standard bi-monthly release workflow for the
development branch of Ubuntu. I think it's important to always have
the most recent version of landscape-client in the development Ubuntu
archive, so that it can get tested through the release process and
problems can spotted out earlier. Hopefully when the release day
comes, our packages are already there since a while and will be
relaxing in front of a few of drinks waiting for the countdown :)
(yeah, it won't happen, but let's dream on..)

Note that the revision number is 0ubuntu1, and not 0ubuntu0.9.10, the
latter is really meant only for backports (see next point).

2) Our SRUs are basically straight backports of our cutting-edge
version to earlier releases, the script that automates the building
of source packages would look something like:

upstream=$(dpkg-parsechangelog | grep ^Version | cut -f 2 -d " "| cut -f 1 -d "-")

for release in dapper_6.06 hardy_8.04; do # all supported releases here

   codename=$(echo $release|cut -f 1 -d _)
   version=$(echo $release|cut -f 2 -d _)
   revision=0ubuntu0.$(echo $version)

   cp debian/changelog ../
   dch -b -v "$upstream-$revision" -D $codename -m "Released for $codename, no source changes."
   dpkg-buildpackage -S
   mv ../changelog debian
done

This would end up in entries like:

landscape-client (1.3.2-0ubuntu0.6.06) dapper; urgency=low

Having a changelog entry which is lesser than the previous is fine for
backports, for example:

http://changelogs.ubuntu.com/changelogs/pool/main/l/lintian/lintian_2.1.2ubuntu1~hardy1/changelog

3) We could possibly have automatic builds against the bzr
version. uploaded to the Landscape PPA. They would be treated
similarly and have versions like 1.3.2~bzr141-0ubuntu0.6.06,
where 141 is the bzr revision.

How does it sound?

I'm glad you appreciate it Chris, it was fun to write it!

[2]

+ update-motd | lsb-base (<< 3.2-14ubuntu2),

This is indeed a tricky and hacky bit. I thought about Recommend as
well, but I find the motd feature very cool and I'd like to make it
very sure that we have it all the time, hence the Depend (although you
are right a Recommend would realistically do the job in most cases).

Now about "| lsb-base (<< 3.2-14ubuntu2)", that basically says "Oh,
and if you don't have update-motd because you are running hardy or
dapper, just don't bother". What happens is that if you are on hardy
or intrepid APT won't find update-modt, and will consider lsb-base <<
3.2-14ubuntu2, which is satisfiable on hardy and dapper. If instead
are on >= intrepid, then "lsb-base (<< 3.2-14ubuntu2)" can't be
satisfied, and APT will be forced to install update-motd. I picked
lsb-base because it doesn't add anything unnecessary, as it is a
package with priority "required", and it will be present in any
installation (it installed by default by debootstrap).

Note also that in landscape-common.postinst we run:

           /usr/sbin/update-motd 2>/dev/null || true

which is safe, in case update-motd isn't there.

[3]
+ python-smartpm | smartpm-core (>= 1.1),

Yeah, we could get rid of it indeed. I just left it because our
smartpm 1.1 packages are actually enough for landscape-1.3.2, is if
somebody doesn't want to upgrade it for some reason, it's still
fine. However I've built smart 1.2 for all our target releases (that's
in my PPA as well), and the plan is indeed to replace the smart 1.1
package in your <= repositories with it.

We need to make the landscape group the primary group for the landscape user, specially when upgrading from previous installations where "nogroup" was the primary group.

The non-root mode is failing, for example:

root@ls5-hardy:~# id landscape
uid=108(landscape) gid=65534(nogroup) groups=65534(nogroup),119(landscape)

root@ls5-hardy:~# /etc/init.d/landscape-client start
 * Starting the landscape-client daemon
start-stop-daemon: Unable to set gid to 119 (Operation not permitted)
   ...fail!
root@ls5-hardy:~#

The initscript tries to use "landscape" as the group when starting the daemon. Changing it back to "nogroup" would workaround it here, but wouldn't work for new installations of the package where "landscape" is the primary group.

After changing the primary group, it works:
root@ls5-hardy:~# usermod -g landscape landscape
root@ls5-hardy:~# id landscape
uid=108(landscape) gid=119(landscape) groups=119(landscape)
root@ls5-hardy:~# /etc/init.d/landscape-client start
 * Starting the landscape-client daemon
   ...done.
root@ls5-hardy:~#

free, can you include a note in README.source about the weird dependency on update-motd and lsb-base? Once this is done, I'm +1 on merging.

Chris, I've added a note to README.source, thanks!

I tested upgrade (via Landscape and not) and install of the 1.3.2 packages in the Landscape PPA on dapper, hardy intrepid and jaunty, qa +1.