Ubuntu
libofx package

Code review comment for lp:~benoitg/ubuntu/natty/libofx/libofx.new-upstream-fix-661809-629996

Revision history for this message

Benoit Grégoire (benoitg) wrote on 2011-04-26:

> Hello! Thanks for the attention to libofx, looks like good stuff.
>
> However, we're too close to natty's release to squeeze this in. And the
> changes are too invasive (changing source format, etc) to use as an SRU.

I tried following: https://wiki.ubuntu.com/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package, as scrupulously as possible, including the "Bonus points" section (Adding watch, etc.). I even created build recipes and automated builds on launchpad for the branch. I thought it would make it easier to get in, apparently that wasn't the case.

Would it make it more acceptable if I remove all the lintian warning removing packaging fixes?

> If the specific patches are very important, you can file an SRU for them that
> includes just the bug fix patches. See
> https://wiki.ubuntu.com/StableReleaseUpdates

Ok, according to this I should get on IRC and yell !regression-alert for bug #629996. That seems silly months later. Then presumably I'd be asked to propose an alternative patch for this bug, cherry-picked from upstream commits. Is that so? If so it's silly, but I'll do it, libofx having been broken by a ubuntu patch for most non-english and non japanese speaking users...

But I DO have 4 years of fixes for upstream reported bugs, ubuntu reported bugs, and debian reported bugs. Some of them are segfaults, which is a problem considering the number of packages that link with libofx. Am I expected to open a SRU for every one of them, then generate and regression an individual patch for each of them individually? Sorry, I have enough trouble as it is finding the time to actually fix the bugs.

The patch looks very invasive, because bzr contains the entire package uncompressed upstream tarball including generated files. But if we forget the (not so big) debian/ changes to follow https://wiki.ubuntu.com/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package and trying to get it back into debian (such as adding ma pages) this would be a simple patch:

-Remove all Ubuntu applied patches
-Update to upstream release 0.9.4
-Remove a dependency on an orphaned package (libxml++1.0) in debian/control
-Add man pages in debian/rules

Would that be considered?

If not, people will have to make do with ppas, and I'll push for integrating this branch in oneiric as is. I think I respected the entire procedure, including doing my best to try to get it into Debian.

> Otherwise, these changes would be able to go into oneiric.
>
> However! Even then, your packaging changes (source format, watch, etc) add
> quite a bit of a delta with Debian. It would be better to send those patches
> upstream to Debian than introduce them only in Ubuntu.

I did, and I am not the first: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551057

Here is the situation (http://packages.debian.org/changelogs/pool/main/libo/libofx/libofx_0.9.0-3/changelog):

- Debian last updated to upstream in 2007, Ubuntu last updated to that package.

- Debian did various local patches in 2008, and haven't touched the package since.

- Upstream kept fixing bugs from 2009-2011, released 4 times, and ultimately superseded every Debian and Ubuntu patch, plus fix every debian bug, all but one Ubuntu bug, and several other bugs reported upstream (including segfaults).

There we are today, Debian hasn't moved (probably in part because of the lack of a watch file I just added).

Now, I don't run Debian, so can't do integration testing there. I tried to contact the maintainer unsuccessfully (directly and indirectly). Several recent upstream changes were specifically to fix Debian issues. The Debian maintainer has an open bug dating from 2009 to upgrade to upstream. There have been 3 additional libofx releases since...

I DO however have fully build tested packages for Ubuntu, build recipes, bzr branches. They are even binary compatible! Rules are rules, but is there anything more I can realistically do at this point? I believe I went above and beyond what most upstream projects would do to try to get it into Debian, AND make Ubuntu's job real easy while respecting Ubuntu's published packaging procedures.

> Lastly, I don't actually see any changes in this merge to the debian/
> directory. Where are the packaging changes?

Modified:

debian/compat
debian/copyright
debian/control
debian/rules
debian/source/format
debian/watch

Removed:
debian/applied-patches/libofx-utf8-rev1.patch

Anyway, I hope I don't sound aggressive, I'm just disappointed (I spent a LOT of time testing all this for Ubuntu, right up to binary compatible PPAs generated directly from upstream source)

> Hello! Thanks for the attention to libofx, looks like good stuff.
> 
> However, we're too close to natty's release to squeeze this in.  And the
> changes are too invasive (changing source format, etc) to use as an SRU.

I tried following: https://wiki.ubuntu.com/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package,  as scrupulously as possible, including the "Bonus points" section (Adding watch, etc.).  I even created build recipes and automated builds on launchpad for the branch.  I thought it would make it easier to get in, apparently that wasn't the case.

Would it make it more acceptable if I remove all the lintian warning removing packaging fixes?

> If the specific patches are very important, you can file an SRU for them that
> includes just the bug fix patches.  See
> https://wiki.ubuntu.com/StableReleaseUpdates

Ok, according to this I should get on IRC and yell !regression-alert for bug #629996.  That seems silly months later.  Then presumably I'd be asked to propose an alternative patch for this bug, cherry-picked from upstream commits.  Is that so?  If so it's silly, but I'll do it, libofx having been broken by a ubuntu patch for most non-english and non japanese speaking users...

But I DO have 4 years of fixes for upstream reported bugs, ubuntu reported bugs, and debian reported bugs.  Some of them are segfaults, which is a problem considering the number of packages that link with libofx.  Am I expected to open a SRU for every one of them, then generate and regression an individual patch for each of them individually?  Sorry, I have enough trouble as it is finding the time to actually fix the bugs.

The patch looks very invasive, because bzr contains the entire package uncompressed upstream tarball including generated files.  But if we forget the (not so big) debian/ changes to follow https://wiki.ubuntu.com/PackagingGuide/Complete#Updating%20an%20Ubuntu%20Package and trying to get it back into debian (such as adding ma pages) this would be a simple patch:

-Remove all Ubuntu applied patches
-Update to upstream release 0.9.4
-Remove a dependency on an orphaned package (libxml++1.0) in debian/control
-Add man pages in debian/rules

Would that be considered?

If not, people will have to make do with ppas, and I'll push for integrating this branch in oneiric as is.  I think I respected the entire procedure, including doing my best to try to get it into Debian.

> Otherwise, these changes would be able to go into oneiric.
> 
> However!  Even then, your packaging changes (source format, watch, etc) add
> quite a bit of a delta with Debian.  It would be better to send those patches
> upstream to Debian than introduce them only in Ubuntu.

I did, and I am not the first: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551057

Here is the situation (http://packages.debian.org/changelogs/pool/main/libo/libofx/libofx_0.9.0-3/changelog):

- Debian last updated to upstream in 2007, Ubuntu last updated to that package.

- Debian did various local patches in 2008, and haven't touched the package since.

There we are today, Debian hasn't moved (probably in part because of the lack of a watch file I just added).

Now, I don't run Debian, so can't do integration testing there.  I tried to contact the maintainer unsuccessfully (directly and indirectly). Several recent upstream changes were specifically to fix Debian issues.  The Debian maintainer has an open bug dating from 2009 to upgrade to upstream.  There have been 3 additional libofx releases since...

I DO however have fully build tested packages for Ubuntu, build recipes, bzr branches.  They are even binary compatible!  Rules are rules, but is there anything more I can realistically do at this point?  I believe I went above and beyond what most upstream projects would do to try to get it into Debian, AND make Ubuntu's job real easy while respecting Ubuntu's published packaging procedures.

> Lastly, I don't actually see any changes in this merge to the debian/
> directory.  Where are the packaging changes?