Bug#630044: transition: poppler 0.16
Pino Toscano
Severity: normal
User: release.d...@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=toscan...@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
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Philipp Kern
the only issue I see at the moment is this:
On Fri, Jun 10, 2011 at 05:03:47PM +0200, Pino Toscano wrote:
> * 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.
There's a claim at the LP bug[1] that the patch isn't suitable. From a casual
look that comment seems wrong, but you can judge this better than me.
If that's resolved I'm ok with you going ahead with this transition. Please
ping me when it's uploaded, though, so that I can take care of the binNMUs.
Kind regards
Philipp Kern
[1] https://bugs.launchpad.net/poppler-python/+bug/696025
Michael Biebl
> Hi,
>
> the only issue I see at the moment is this:
>
> On Fri, Jun 10, 2011 at 05:03:47PM +0200, Pino Toscano wrote:
>> * 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.
>
> There's a claim at the LP bug[1] that the patch isn't suitable. From a casual
> look that comment seems wrong, but you can judge this better than me.
>
> If that's resolved I'm ok with you going ahead with this transition. Please
> ping me when it's uploaded, though, so that I can take care of the binNMUs.
>
> Kind regards
> Philipp Kern
>
> [1] https://bugs.launchpad.net/poppler-python/+bug/696025
Jakub mentioned on irc that the patch in [1] is wrong.
There's an alternate patch shipped in the fedora package.
I've attached this patch and hope the more python/poppler savvy people can take
a look at it.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
I did a test-rebuild of those packages last friday against poppler 0.16.7-1 from
experimental.
It turns out, out of these packages gdcm is currently not buildable and fails
during configure. I filed a bug for that [1].
Even after fixing that, the package still ftbfs, due to vtk not being multiarch
ready [2]. Afaics there is no easy fix for the vtk issue and no clear timeframe
when such a fix would be ready.
As a consequence I asked on irc if (temporarily) removing gdcm from testing
would be an option. According to adsb this would affect
gdcm ants insighttoolkit mriconvert
Both adsb and mehdi were ok with that, so I'm planning on uploading poppler to
0.6.17-2 later today.
Cheers,
Michael
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632406
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629815
Pino Toscano
> I'm planning on uploading poppler to 0.6.17-2 later today.
poppler 0.16.7-2 uploaded and built correctly on every release arch (and
more), could you please schedule the binNMUs for the packages above
(excluding gdcm, currently broken)?
Thanks,
--
Pino Toscano
Philipp Kern
Not yet done for epdfview and libreoffice. Done for the others.
Kind regards,
Philipp Kern
--
.''`. Philipp Kern Debian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp:ph...@0x539.de Wanna-Build Admin
`- finger pkern/k...@db.debian.org
Philipp Kern
> Not yet done for epdfview and libreoffice. Done for the others.
Now done for epdfview and libreoffice, too.
Kind regards
Philipp Kern
Pino Toscano
> On Mon, Jul 04, 2011 at 01:07:01PM +0200, Philipp Kern wrote:
> > Not yet done for epdfview and libreoffice. Done for the others.
>
> Now done for epdfview and libreoffice, too.
Sorry, I missed also calibre (which uses the libpoppler-dev material by
means of libpoppler-qt4-dev). Could you please binNMU it as well (it
should build fine), and add it to the transition tracker?
Thanks,
--
Pino Toscano
Philipp Kern
am Mon, Jul 04, 2011 at 06:21:51PM +0200 hast du folgendes geschrieben:
the transition tracker isn't manual. So either it doesn't need a binNMU
because it doesn't directly link it or the expression for the list of affected
packages is wrong (on the top of the page).
Pino Toscano
> Pino,
>
> am Mon, Jul 04, 2011 at 06:21:51PM +0200 hast du folgendes
geschrieben:
> > Alle lunedì 4 luglio 2011, Philipp Kern ha scritto:
> > > On Mon, Jul 04, 2011 at 01:07:01PM +0200, Philipp Kern wrote:
> > > > Not yet done for epdfview and libreoffice. Done for the
> > > > others.
> > >
> > > Now done for epdfview and libreoffice, too.
> >
> > Sorry, I missed also calibre (which uses the libpoppler-dev
> > material by means of libpoppler-qt4-dev). Could you please binNMU
> > it as well (it should build fine), and add it to the transition
> > tracker?
>
> the transition tracker isn't manual. So either it doesn't need a
> binNMU because it doesn't directly link it or the expression for the
> list of affected packages is wrong (on the top of the page).
The list is correct, generally -- it's just calibre using a build
depenency because it is pulled directly from another one.
For "adding" I was referring to the conditions of the affected packages,
like i saw a ".package" condition in the python2.7 tracker page. If it
isn't the case, sorry for the mistake, and then just add the libpoppler-
qt4-dev b-d to the affected conditions.
Thanks,
--
Pino Toscano
Philipp Kern
> The list is correct, generally -- it's just calibre using a build
> depenency because it is pulled directly from another one.
> For "adding" I was referring to the conditions of the affected packages,
> like i saw a ".package" condition in the python2.7 tracker page. If it
> isn't the case, sorry for the mistake, and then just add the libpoppler-
> qt4-dev b-d to the affected conditions.
Added, let's wait for the next update.
Michael Biebl
here's a short update on the poppler transition:
as can be seen on [1], all rdeps besides libreoffice (mips/el) and gdcm have
been built and should be ready.
gdcm:
Even with [2] fixed, gdcm still ftbfs due to VTK being buggy wrt multiarch [3].
This can be temporarily worked around by binNMUing VTK to pick up the new
library locations [4]. After that, gdcm should be binNMUable again.
Julien seems to favor getting a proper fix for VTK though, even if that would
most likely mean to remove gdcm from testing for the time being.
libreoffice:
LO ftbfs on mips(el). Rene believes this to be a buildd issue and as he told me
on irc is waiting for help from the mips porters, which hasn't happened so far.
Would be nice to know, how the release team plans to handle those two issues, so
we can get the transition done.
Cheers,
Michael
[1] http://release.debian.org/transitions/html/poppler.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631497
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506992
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506992#24
Rene Engelhard
On Sun, Jul 10, 2011 at 05:35:19PM +0200, Michael Biebl wrote:
> Julien seems to favor getting a proper fix for VTK though, even if that would
> most likely mean to remove gdcm from testing for the time being.
>
> libreoffice:
> LO ftbfs on mips(el). Rene believes this to be a buildd issue and as he told me
> on irc is waiting for help from the mips porters, which hasn't happened so far.
Not completely true. I said it's a *port* issue. Whether it's also a buildd issue or
not is beyond my scope, but as said to Michael on IRC - mips built fine on gabrielli.
mipsel has no porterbox, so.. :(
> Would be nice to know, how the release team plans to handle those two issues, so
> we can get the transition done.
Unless some MIPS porter does something (I see that libreoffice was requeued on
lucatelli - same hw as gabrielli - let's see whether that builds; it's still
"Building", so there's hope) I'd suggest to remove the "obsolete" binaries.
Grüße/Regards,
René
Julien Cristau
> Hi,
>
> On Sun, Jul 10, 2011 at 05:35:19PM +0200, Michael Biebl wrote:
> > Julien seems to favor getting a proper fix for VTK though, even if that would
> > most likely mean to remove gdcm from testing for the time being.
> >
> > libreoffice:
> > LO ftbfs on mips(el). Rene believes this to be a buildd issue and as he told me
> > on irc is waiting for help from the mips porters, which hasn't happened so far.
>
> Not completely true. I said it's a *port* issue. Whether it's also a buildd issue or
> not is beyond my scope, but as said to Michael on IRC - mips built fine on gabrielli.
> mipsel has no porterbox, so.. :(
>
> > Would be nice to know, how the release team plans to handle those two issues, so
> > we can get the transition done.
>
> Unless some MIPS porter does something (I see that libreoffice was requeued on
> lucatelli - same hw as gabrielli - let's see whether that builds; it's still
> "Building", so there's hope) I'd suggest to remove the "obsolete" binaries.
>
Did you contact debian-mips@ about that issue? I don't see anything
from you there in the last couple months.
Cheers,
Julien
Debian Bug Tracking System
with message-id <20110724094...@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 ow...@bugs.debian.org
immediately.)
--
630044: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630044
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems