Merge lp:~richard-wilbur/bzr-dbus/fix-old-glib into lp:bzr-dbus

[Richard Wilbur]

In trying to avoid deprecated python-gobject interfaces, the bzr-dbus code was migrated to use python-gi. Developers with the newest versions of the code and documentation used a new 4-parameter version of the GLib.io_add_watch() call to avoid deprecation warnings. It turns out that is only supported in the most recent versions of python-gi (>=3.8.0-2) shipped with Ubuntu 13.04 (raring) and beyond.

Caught the exception generated by the unsupported call and used that as the cue to issue the older 3-parameter call. Presently precise and quantal fail the selftests because of this error.

[Robert Bruce Park (robru)]

Looks good to me. Feel free to merge it when you're ready (I don't have permission to myself).

review: Approve

[Richard Wilbur (richard-wilbur)]

Robert, thanks for the help. The recipe was just what I needed. I understood the local version control things but the interaction with launchpad and its relation to branches was new territory.

I started a build on 'precise' and it said it will take ~1 hour. So we're in the queue and I'll check it later.

[Richard Wilbur (richard-wilbur)]

Requested builds worked on 'precise', 'quantal', and 'raring' for the new code merged from this branch. Automatic builds failed today because something about the uploads failed.[0]

[0] https://launchpad.net/~bzr/+archive/daily/+recipebuild/458259/+files/upload_458259_log.txt

[Robert Bruce Park (robru)]

Did you trigger a manual build on the recipe page? That error message indicates that two different builds were attempted with the same version number of the package, except that the contents didn't match. This often happens when the version string consists only of revision numbers (as this one does) and you attempt to trigger a manual build (as opposed to pushing a new commit to trigger a new build).

Potential solutions include:

1. Do nothing. Just wait for the next commit to trunk to trigger a new build.

2. Make a trivial change and commit it directly to trunk. This will bump the revno and allow the upload to succeed.

3. Change the version string used to include a time component. Something like this is the most verbose:

# bzr-builder format 0.3 deb-version {debupstream-base}bzr{revno}~ppa{revno:packaging}~{time}

However I like to keep things simple and most of my personal recipes tend to look more like this:

# bzr-builder format 0.3 deb-version {debupstream-base}bzr{time}

Or even:

# bzr-builder format 0.3 deb-version 0:{time}

If you opt for the last one there, just make sure that '0' is some number larger than the existing version, otherwise the version in the PPA won't be installable because the version in distro will be considered "newer". So the first of the three is safest.

[Richard Wilbur (richard-wilbur)]

I did trigger a manual build on the recipe page after I merged the new version into trunk. My curiosity got the best of me as I was interested to see whether the new version would only solve the syntax error or fix the whole selftest. All of the manual builds succeeded and then the automatic ones for the configured targets failed: precise, quantal, raring.

Thank you for confirming my suspicions and offering a solution. I chose the full-blown solution because it was the safest and also the closest to what we already have. I have applied it to the recipe.

[Richard Wilbur (richard-wilbur)]

Robert, I fixed the recipe. Is there a way to try out the automatic builds (that failed) without submitting a new version of source code?

[Robert Bruce Park (robru)]

As long as the recipe has the {time} component in the version string, you can click on 'request build' and it should work fine.

[Richard Wilbur (richard-wilbur)]

When I selected 'request build' I was presented with the option to build for Saucy, Raring, Quantal, Precise, and Lucid. In order to get maximum test coverage, and because I expected it to work, I selected each of these possibilities. Here is a representative response from "Ubuntu Installer" <email address hidden> for Raring[1], Quantal[2], and Precise[3]:

Rejected:
bzr-dbus_0.1~bzr55~ppa91~201305142015~raring1.dsc: Version older than that in the archive. 0.1~bzr55~ppa91~201305142015~raring1 <= 0.1~bzr55~ppa91~raring1

Saucy didn't build anything, just set up the changeroot build environment, so it succeeded in everything it tried to do.[4] It reported success but didn't build any packages.

Lucid stopped dead in its tracks with[5]:
Build status
[MANUALDEPWAIT] Dependency wait on nannyberry (virtual)
    Missing build dependencies: python-gi

I doubt that will ever be resolved on Lucid unless we change the packaging to allow an alternate.

[1] https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/460880
[2] https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/460881
[3] https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/460882
[4] https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/460879
[5] https://code.launchpad.net/~bzr/+archive/daily/+recipebuild/460883

[Robert Bruce Park (robru)]

Ok, so it's a bit confused about the version numbering. Just prepend the version string with "1:" in the recipe and that'll force it to accept the new format as newer than the previous format.

You're right, Lucid is unsupported and nobody will ever backport pygi to it. Don't bother building for that.

And you're wrong about saucy, I see it in the PPA. It's just the same problem with the version numbering. Same fix above will fix saucy.

[Richard Wilbur (richard-wilbur)]

I added a 't' before the {time}, as in
# bzr-builder format 0.3 deb-version {debupstream-base}bzr{revno}~ppa{revno:packaging}~t{time}

to make it > than the old version string which had the distribution name at that spot:
0.1~bzr55~ppa91~raring1
The new string:
0.1~bzr55~ppa91~t201305152302~raring1

This worked and the triggered builds all succeeded: precise, quantal, raring.

You were right about saucy, somehow I only looked at the chroot build log and not the actual package build log (which showed success).

=== modified file 'activity.py'
--- activity.py	2013-03-21 05:57:40 +0000
+++ activity.py	2013-05-08 20:05:33 +0000
@@ -328,7 +328,12 @@
             self.port = self.sock.getsockname()[1]
         else:
             self.port = _port
-        GLib.io_add_watch(self.sock, GLib.PRIORITY_HIGH, GLib.IO_IN, self.handle_network_packet)
+        try:
+            # Priority arg first works in python-gi: 3.8.0-2 (raring)
+            GLib.io_add_watch(self.sock, GLib.PRIORITY_HIGH, GLib.IO_IN, self.handle_network_packet)
+        except TypeError:
+            # Needed for python-gi: 3.2.2-1~precise, 3.4.0-1ubuntu0.1 (quantal)
+            GLib.io_add_watch(self.sock, GLib.IO_IN, self.handle_network_packet)
         # listen for dbus events
         self.activity.listen_for_revisions(self.catch_dbus_revision)
 

=== modified file 'tests/test_activity.py'
--- tests/test_activity.py	2013-03-21 05:57:40 +0000
+++ tests/test_activity.py	2013-05-08 20:05:33 +0000
@@ -183,7 +183,7 @@
             "%r is not %r" % (obj.bus, dbus.SessionBus()))
 
     def test_server(self):
-        """Calling Activity.serve() provides a convient means to serve."""
+        """Calling Activity.serve() provides a convenient means to serve."""
         # to test the server, we can't easily run it in process due to
         # apparent glib/dbus/dbus-python interactions: so we fire it off
         # externally. As all the server does is serve requests until its