[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#630044: marked as done (transition: poppler 0.16)



Your message dated Sun, 24 Jul 2011 11:46:09 +0200
with message-id <20110724094609.GP32052@radis.liafa.jussieu.fr>
and subject line Re: Bug#630044: transition: poppler 0.16
has caused the Debian Bug report #630044,
regarding transition: poppler 0.16
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
630044: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630044
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Hi,

I would like to ask a slot for a Poppler 0.16.x transition.
There are new versions of packages which start to require an updated
Poppler, and our current version (0.12.x) is a bit old.
Currently we have Poppler 0.16.3 in experimental already, and Poppler
0.16.6 is planned for unstable (same SONAMEs for libraries as 0.16.3).

This transition impacts the existing poppler libraries in the following
ways:
- libpoppler5 → libpoppler13
- libpoppler-glib4 → libpoppler-glib6
- libpoppler-qt2 -- qt3 frontend, dropped (no rdeps in testing & sid)
- libpoppler-qt4-3 -- BC with 0.12, but bumps shlibs

Below it is a list of sources which are touched by the transition,
and their situation, sorted by solutions:

Sources that can be binNMU'ed:

  apvlv (poppler-glib)
  auto-multiple-choice (poppler)
  cups (poppler)
  epdfview (poppler-glib)
  gambas2 (poppler)
  gdcm (poppler)
  gimp (poppler-glib)
  gpdftext (poppler-glib)
  gnome-commander (poppler)
  gummi (poppler-glib)
  inkscape (poppler, poppler-glib)
  koffice (poppler)
  libreoffice (poppler)
  luatex (poppler)
  pdf-presenter-console (poppler-glib)
  pdf2djvu (poppler)
  pdf2svg (poppler-glib)
  pdfcube (poppler-glib)
  pdfgrep (poppler)
  pdftoipe (poppler)
  popplerkit.framework (poppler)
  referencer (poppler-glib)
  ruby-gnome2 (poppler-glib)
  texlive-bin (poppler)
  tracker (poppler-glib)
  tumbler (poppler-glib)
  xournal (poppler-glib)
  webkit2pdf (poppler-glib)
  zathura (poppler-glib)

Sources that need a custom solution:

* evince (poppler-glib)
    evince 2.30 does not support poppler-glib 0.16. The solution which
    Michael Biebl, Josselin Mouette and me discussed was to update to
    evince 2.32 (which though requires poppler 0.14, so cannot be
    uploaded right now) + a needed upstream patch to unstable, aside
    gnome-python-desktop 2.32 too (g-p-d 2.30 does not support evince
    2.32).
    (Please note evince 2.23 would need to pass through NEW, and
    experimental has evince 3.x already.)

* poppler-sharp (poppler-glib)
    This is an arch:all package, so it needs a sourceful upload.
    A couple of months ago, I talked with Chow Loong Jin (hyperair,
    CC'ed) on IRC about this transition, and he told me that he knew
    about this already, and he had to fix this manually, and to let him
    know about the transition time.
    This package has only one rdepend, pdfmod.

* python-poppler (poppler-glib)
    The (small) patch needed to compile with poppler 0.16 is not
    compatible with poppler 0.12, so it cannot be uploaded right now.
    Asked to provide a version in experimental compilable with poppler
    0.16, see #628047.

* xpdf (poppler)
    The (small) patch needed to compile with poppler 0.16 is not
    compatible with poppler 0.12, so it cannot be uploaded right now.
    Asked to provide a version in experimental compilable with poppler
    0.16, see #627667.

Other cases:

* derivations (poppler)
    This source builds a libpoppler-based utility application which is
    only used during the build to generate other data, and no trace of
    that application are left in the resulting arch:all package.
    This source can be left out of the transition.


I grouped all the bugs mentioned above (even the solved ones) with the
following usertag:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=toscano.pino@tiscali.it;tag=poppler-0.16

Possible conflicts with other transitions:
* inkscape is part of the current imagemagick4 transition (#625544)
* poppler-sharp is a mono/CLI package, and I saw there is a transition
  tracker for a mono transition (but no transition bug open, yet?),
  so most probably this transition should be done before or after the
  mono one
* webkit2pdf possibly could be in common with the asked (but not yet
  ack'ed, though) webkit transition (#622371)

In the end, to help you according to other transition trackers:
- "affected" packages: b-d on libpoppler-dev or libpoppler-glib-dev
- "bad" packages: depends on libpoppler5 or libpoppler-glib4
- "good" packages: depends on libpoppler13 or libpoppler-glib6

Thanks,
-- 
Pino



--- End Message ---
--- Begin Message ---
On Fri, Jun 10, 2011 at 17:03:47 +0200, Pino Toscano wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I would like to ask a slot for a Poppler 0.16.x transition.

   poppler |   0.16.7-2 |       testing | source

Closing.

Cheers,
Julien


--- End Message ---

Reply to: