FFe: Sync libgxps 0.2.1-1 (universe) from Debian testing (main)

Package uploaded and awaiting sponsorship: http://mentors.debian.net/package/libgxps

*** 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.

Savvas, this currently can't land in Ubuntu Precise because it depends on libarchive 3. You could file a FFe for libarchive 3 but I don't know if it would be approved. Otherwise, this should happen automatically for Ubuntu Q.

https://wiki.ubuntu.com/FreezeExceptionProcess

FTBFS libarchive 3.x (dependency of libgxps) on i386 arch - patch available, comment #15:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/951139

I uploaded the libarchive FTBFS fix, so you should be able to sync this in an hour or two.

Thank you! 3.0.3-6ubuntu1 builds fine now.

I hope we're not too late, with the beta freeze in effect. :)
There's an even newer version in unstable (0.2.2-1): http://packages.qa.debian.org/libg/libgxps.html

libgxps (0.2.2-1) unstable; urgency=low

   * New upstream release.
   * Bump Build-Depends on cdbs for multiarch support.
   * debian/patches/01_fix-gtk-doc-build.patch: Removed, merged upstream.

Package cdbs is version 0.4.100ubuntu2 in precise, so it's ok to assume it will work. I'll test-build it this evening.

http://ftp.gnome.org/pub/gnome/sources/libgxps/0.2/libgxps-0.2.2.news

libgxps 0.2.2 (19 March 2012)
=============================

Bug fixes:

    - Fix COPYING file that used lgl2 instead of lgpl2.1 (#671271,
      Carlos Garcia Campos)
    - Fix the build with --enable-gtk-doc (#671274, Michael Biebl)
    - Fix several memory leaks when parsing fails (#668937, #668940,
      #668941, #668969, #668968, #668966, #668965, Jason Crain)

Tools:

    - Set image parameters after jpeg_set_defaults(), so the
      resolution does not get overwritten by the defaults (Adrian
      Johnson)

Documentation:

    - Ignore private headers when generating API doc (Carlos Garcia
      Campos)
    - Add index of new symbols in 0.2.1 (Carlos Garcia Campos)
    - Add Since: tag to GXPS_VERSION_STRING api docs (Carlos Garcia
      Campos)

Are there any intended reverse dependencies of this library?

(if Evince, this will have to go to main which will entail a MIR)

Falling back to libgxps 0.2.1-1 suggestion - current cdbs in precise is 0.4.100ubuntu2 and does not satisfy the depenencies of libgxps 0.2.2-1:
https://launchpadlibrarian.net/98042540/buildlog_ubuntu-precise-amd64.libgxps_0.2.2-1~ppap1_FAILEDTOBUILD.txt.gz

>Are there any intended reverse dependencies of this library?
Yes, evince
> (if Evince, this will have to go to main which will entail a MIR)
should I change from (universe) to (main) then?

We do have the necessary version of cdbs, so should sync the most recent libgxps (I just tested that it builds fine).

I'd like someone from the desktop team to comment on whether the Evince support is wanted this cycle though, otherwise we should look again in Q.

I wasn't referring to the bug title, but the fact that the MainInclusionProcess will need to be followed, as the package will become a dependency of evince and therefore will need to go to main. It might be a bit late in the cycle for this.

You're right, it must've been a ppa build mistake. I tried it again and it works now, thanks.

It would've been faster if revu was still working. :) I had to wait for it to be included in Debian, then apply for FFe.
I also had to wait for the inclusion of libarchive 3.x - at least libarchive made it.

Thank you for the clarification! Do I have to subscribe the desktop-bugs team?

Yes, I agree that it's rather late, but depending on how this is integrated into evince it does not sound very risky. But let's discuss the MIR first.

Let's sync to universe and handle the MIR separately then. FFe approved.

Sponsored, waiting in NEW.

This bug was fixed in the package libgxps - 0.2.2-1
Sponsored for Savvas Radevic (medigeek)

---------------
libgxps (0.2.2-1) unstable; urgency=low

  * New upstream release.
  * Bump Build-Depends on cdbs for multiarch support.
  * debian/patches/01_fix-gtk-doc-build.patch: Removed, merged upstream.

 -- Michael Biebl <email address hidden> Mon, 19 Mar 2012 15:28:37 +0100

libgxps (0.2.1-1) unstable; urgency=low

  [ Savvas Radevic ]
  * Initial release (LP: #912789) (Closes: #654892)

 -- Michael Biebl <email address hidden> Thu, 08 Mar 2012 16:00:35 +0100

Thank you very much! I'm quite happy with the partial xps support.
Now:
1. Can I file the MIR request or must an Ubuntu developer do that?
2. Do I have to file a new bug for libgxps and request MIR (stands for "main inclusion request" I presume?) or should I use the evince bug ( https://bugs.launchpad.net/ubuntu/+source/evince/+bug/375038 ) ?
3. Also, do I follow the MIR procedure described at https://wiki.ubuntu.com/UbuntuMainInclusionRequirements ?

> I'm quite happy with the partial xps support.
I mean I'm satisfied even if evince xps support is not approved. I realize that we're kind of late in the precise development cycle.

Savvas, anyone can file a MIR. You can either create a new bug or rewrite that existing bug.

And yes, that wiki page gives the procedures.

The procedure which you need to follow is at https://wiki.ubuntu.com/MainInclusionProcess . Anyone can file the report; you need not be a developer. If and when the MIR is approved, you should then request sponsorship (and FFe) for the change in Evince. I don't want to get your hopes up too much — the cycle is drawing to a close — it may not get into Precise, but the work on the MIR will not be wasted as it'll have to happen in Q cycle anyway.

I hope this is OK: https://bugs.launchpad.net/ubuntu/+source/libgxps/+bug/965467