[needs-packaging] goocanvas 2.0

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

This will be needed by Glom 1.20.

Could you email <email address hidden> to let them know that you are working on that update as well?

Note that the update there is a bit problematic since the new version seems to drop GTK2 support, what does it mean for its rdepends? for example libgoo-canvas-perl depends on libgoocanvas3 and shutter uses libgoo-canvas-perl, does it mean that if goocanvas is updated shutter will be broken? We might want to delay the update to after the LTS (or have 2 different goocanvas sources for a gtk2 and a gtk3 build)

> the new version seems to drop GTK2 support,

Yes, the new version installs in parallel with the old version. Lots of libraries have done this recently.

> 2 different goocanvas sources for a gtk2 and a gtk3 build

Yes, of course.

> Lots of libraries have done this recently.

quite some took the "let select the gtk version to use at configure time" which allows to build both from the same source, but yeah, both way work

The source package will need to be renamed there then since it's not supposed to replace 0.15

What's the standard here? I've already renamed the binary package to
libgoocanvas-2.0{,-common,-dev}. Should the source package just be
goocanvas-2.0 ? (I'm kind of confused by the existence of a
libgoocanvas3 package which just contains version 0.15).

Thanks Timo, I see the merge request is active again which good, just to update the bug the package has been submitted to Debian: http://mentors.debian.net/package/goocanvas-2.0

Those interested in the review details should read https://code.launchpad.net/~tkluck/ubuntu/oneiric/goocanvas/v2/+merge/83284 or look at https://code.launchpad.net/~tkluck/debian/sid/goocanvas/v2.0

Timo, would you be interested to work on other packages like gda5 or glom as well once goocanvas settles?

Can you explain (or find a link) where the soname number comes from?
In this case, the libtool library version info is equal to 11:0:2.
Where does the 9 come from? Guess: it's 11 - 2, but why?

Relatedly, should I manually rename the binary package (and only the
binary package?) to libgoocanvas-2.0-9 in debian/control, or should I
do it with some variable substitution?

[1] https://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html

Another question: in addition to libgoocanvas-2.0-9, should there be a
metapackage called libgoocanvas-2.0 that always depends on the current
version? Should this package be made from the same source package?

Reviewing your updated https://code.launchpad.net/~tkluck/debian/sid/goocanvas/v2.0

* it seems to be mostly ok

* "dh_install: usr/lib/python2.7/site-packages/gi/overrides/GooCanvas.py exists in debian/tmp but is not installed to anywhere"

-> you need to install this one

* the libgoocanvas-2.0 dummy packages should be dropped, dynamic libraries can't get the current version, they get the current -dev and depends on the version they built again, if you want to depend on a new version you need a rebuild which will pick the updated soname depends for you

> * "dh_install: usr/lib/python2.7/site-packages/gi/overrides/GooCanvas.py
> exists in debian/tmp but is not installed to anywhere"
>
> -> you need to install this one
This one is only created if you have python-gobject-2-dev installed,
which is deprecated. Do you think I should add a build dependency on
that one regardless? For now, I've added --disable-python to
debian/rules.

>
> * the  libgoocanvas-2.0 dummy packages should be dropped, dynamic
> libraries can't get the current version, they get the current -dev and
> depends on the version they built again, if you want to depend on a new
> version you need a rebuild which will pick the updated soname depends
> for you
Done.

I just pushed a new version to launchpad.

Is there a chance that goocanvas 2.0 will be available in Precise? I am about to port some projects of mine from PyGTK to PyGI/GTK3, but since I use python-goocanvas in one project, this is currently holding me back. I’d be so happy to finally make the transition in time for Precise.

The package should be okay for Debian now, but it probably won't make it in time for the sync. I'll make a package for precise, too. Hopefully, Sebastien can review + upload it.

I uploaded goocanvas-2.0 to Ubuntu precise. I just took the liberty to change the changelog entry to the following:

 goocanvas-2.0 (2.0.1-0ubuntu1) precise; urgency=low
 .
   * New upstream version (LP: #858954):
     - Now uses Gtk+3
     - Allow version 0.15 and 2.0 to be installed simultaneously

(Change of version number, changed unstable to precise, added bug number to changelog entry.)

Because this is going to be a new source package, this should now be sitting in the queue of the archive admins.

Iain: I felt I should subscribe you to the bug, as I took the liberty of getting the package into Ubuntu, so we can crack on and get the other source packages in place.

AFAICS https://code.launchpad.net/~tkluck/debian/sid/goocanvas/v2.0 should be ready to get into Debian and afterwards we should be able to sync.

Cheers. I am repeatedly pinging jsogo but in the absence of any response RSN I will do something about it (i.e. NMU or hijack)

Any news on this one? I hope I am not getting on anyone’s nerves, but it would be sad to miss Precise for this.

Still in the archive admin queue: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=goocanvas

Accepted.