Bug 117495 - app-text/{poppler|xpdf} first Xpdf round this year
|
Bug#:
117495
|
Product: Gentoo Security
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: jaervosz@gentoo.org
|
|
Component: Vulnerabilities
|
|
|
URL:
|
|
Summary: app-text/{poppler|xpdf} first Xpdf round this year
|
|
Keywords:
|
|
Status Whiteboard: B2 [glsa] jaervosz
|
|
Opened: 2006-01-02 14:52 0000
|
Stub for now, details will follow.
Comment #9 From Daniel Gryniewicz 2006-01-05 10:16 PST
poppler is bumped to poppler-0.4.3-r4 with this fix. Xpdf is not yet done.
Arches please test and mark stable.
There are two problems with marking new poppler stable:
1) utils have moved from xpdf to poppler
If you mark the new poppler stable you also need to make sure that a newer xpdf
is marked stable because poppler blocks older xpdf versions.
Furthermore you should make sure that the currently stable-on-the-arch cups
should depend on the new poppler instead of xpdf.
2) bindings have been split out from poppler into poppler-bindings
You need to mark poppler-bindings stable and change the depend on poppler to
poppler-bindings in the stable kpdf and kdegraphics ebuild to make sure they
still work afterwards.
hmm.. I don't have poppler-bindings installed, but kpdf still works (= displays
PDFs correctly)
was I to fast in marking stable?
(In reply to comment #5)
> was I to fast in marking stable?
>
Looks that way. What are we supposed to do here? Sounds like a bunch of other
ebuilds need to have their deps updated for poppler-bindings? Also sounds like
all of this (xpdf, poppler, cups) needs to go stable at the same time or we get
versions going up/down.
your kpdf probably links on xpdf then, can you please check that?
linking on xpdf is not desired and it should be possible to link on
poppler/poppler-bindings
I suggest adding a || ( poppler-bindings <poppler-0.4.3-r2 ) DEPEND to the
affected ebuilds for the transition period.
Handling stable marking of xpdf here as poppler and old xpdf versions are
blocking.
Printing are we ready to mark stable?
[09:29:03] <@genstef> jaervosz: yes we are ready for stable
Arches please test and mark stable.
Back to ebuild to fix KDE deps.
Adding net-print/cups-1.1.23-r7 to the list of packages that need to go stable
at the same time.
after
emerge -Cav poppler xpdf
then
emerge -av poppler xpdf
did work fine. Readed about that in an other bug. Strange fix, but works for me
on ~x86
I marked these hppa stable:
app-text/poppler-0.4.3-r4
app-text/xpdf-3.01-r5
net-print/cups-1.1.23-r7
app-text/poppler-bindings-0.4.3-r2
Is that the full list? If there are more packages to test and mark, could
someone ITK please make note of them, including category and version?
Michail: genstef was nice enough to help and took care of the blocking issues,
so this should work perfectly now.
KDE please confirm that deps are OK with you.
[21:50:57] <genstef> jaervosz: kde deps are ok
[21:57:05] <genstef> kpdf, kdegraphics just need to make sure to remove the
not-latest-unstable-or-stable versions
[22:03:37] <genstef> well, it would be of course good to mark the latest cups
stable :)
Arches please test, mark stable and watch out for dep issues:-)
app-text/poppler-0.4.3-r4
app-text/xpdf-3.01-r5
net-print/cups-1.1.23-r7
app-text/poppler-bindings-0.4.3-r2
marked ppc stable ... currently hppa and ppc64 seems to have broken deps.
(In reply to comment #20)
> currently hppa and ppc64 seems to have broken deps.
bleh, forget about this ... i haven't cvs'upd in x11-libs/cairo :/
stable on ppc64 (now realy...)
Deps are still not fixed. The poppler-bindings thing was only added to the
latest ~arch KDE ebuilds.
It is not needed by the arch(stablle)-kpdf ebuild because it depends only on
pdfinfo which is in poppler and not in poppler-bindings
There seems to be a weird dependency issue on x86 now:
Calculating dependencies ...done!
[blocks B ] <app-text/xpdf-3.01-r4 (is blocking app-text/poppler-0.4.3-r4)
[ebuild U ] app-text/poppler-0.4.3-r4 [0.4.3] -cairo +jpeg +zlib 45 kB
[ebuild U ] app-text/xpdf-3.01-r5 [3.01-r3] +X 0 kB
U just have to unmerge xpdf-3.01-r3 before merging xpdf-3.01-r5 to fix but IMHO
portage should have handled that for me .
(In reply to comment #28)
> U just have to unmerge xpdf-3.01-r3 before merging xpdf-3.01-r5 to fix but IMHO
> portage should have handled that for me .
Please, don't clutter security bugs with completely unrelated things, and also
search for duplicates first (Bug 116933).
Alpha any news on this one?
