Pushing kde4 into testing

Adeodato Simó dato at net.com.org.es
Tue May 12 10:29:14 UTC 2009


(Bcc Debian Edu: please search for "libqt-perl" in this message.)

+ Sune Vuorela (Mon, 11 May 2009 23:29:14 +0000):

> Short version: We need to act now before we get caught with the new
> boost things, kde4 looks better now that I expected - and better than I
> expect it to be within the next month or so.

> Everything of KDE4 that uses boost will fail with the new boost-defaults
> as kde4 has checks for explicit versions, and 1.38 is not in the list of
> versions it knows about. 

> Maybe the best thing is to push everything now, let some things be
> broken for a while and then fix up afterwards.
> A bit of things is unbuilt on hppa and mips*, as they as you all know
> have been having issues lately and haven't fully recovered.

> The alternative is that we wait and pushes newer kde packages to
> unstable and hope everything is better in a month, with whatever
> blockings that will give.
> It is also unclear if other or same archs will be at a different
> condition later on.

> Longer version:
> Adeodato identified some issues (quoted - and my comments added)
> Moste of this will be a story about omelettes and eggs and how long to
> wait for maintainers to consider how to fix their issues.

> |Packages rendered uninstallable by KDE4 and that don't seem to have a
> |fixed version in unstable:

> All these issues have existed in unstable for a little more than a
> month.

> |bulmages-common (= 0.11.1-2): FAILED
> |The following constraints cannot be satisfied:
> |  bulmages-common (= 0.11.1-2) depends on kpdf {NOT AVAILABLE}

> "Maintainer will fix one day in the future" - Remove it from testing
> now, it should easy flow back once it is fixed.

> Bulmages is a spanish accounting program for small businesses.
> Users who really needs it can get bulmages from stable.

This is #522584, which I thought had not been filed; my fault. The bug
has been open for more than a month at RC severity: I gave maintainer
one last notice, will remove if necessary.

> |digikam-doc (= 0.9.5-1): FAILED
> |The following constraints cannot be satisfied:
> |  digikam-doc (= 0.9.5-1) depends on khelpcenter {NOT AVAILABLE}

> Let's remove this temporarily, it is documentation for the kde3 edition
> of digikam/lenny anyways.
> Maintainer says: remove it for now.

Okay.

> |knights (= 0.6-8.2): FAILED
> |The following constraints cannot be satisfied:
> |  knights (= 0.6-8.2) depends on kdebase-kio-plugins {NOT AVAILABLE}

> Package unmaintained and up for adoption - and haven't had a maintainer
> upload since 2007.

> Unless we start NMU'ing / QA uploading it, it will stay broken.
> Let us remove it from testing for now, hoping for a adopter.

Would you care to file an RC bug at least? But I'm okay with removing
this one.

> |opensync-plugin-kdepim (= 0.22-3): FAILED
> |The following constraints cannot be satisfied:
> |  opensync-plugin-kdepim (= 0.22-3) depends on libkcal2b (>= 4:3.5.8) {NOT AVAILABLE}

> Maintainer aware and have had more than a month to fix it, including
> finding patches over in fedora-land. Maintainer will fix within weeks or
> months. I'm not suer it is worth waiting for. A fixed version will go
> easy to testing once ready.

Fixed version uploaded by the maintainer. Should be built everywhere
soon.

> |taskjuggler (= 2.4.1-1): FAILED
> |The following constraints cannot be satisfied:
> |  taskjuggler (= 2.4.1-1) depends on libkcal2b (>= 4:3.5.9) {NOT AVAILABLE}

> Taskjuggler will be fixed one day. Maintainer is aware and have been it
> since around lenny release. Maintainers are part of the debian kde team.
> A fixed version (either using libical directly, or by removing the kcal
> features) should easy go back to testing once ready

Care you file an RC bug? Please ask the maintainers to state their
plans, saying it'll be removed if they don't react soon. (I'm aware
you've probaby been in contact with the maintainers by IRC or whatever,
but bugs are more easily found by other teams, particularly the RT;
please remember that.)

> |soundkonverter-amarok (= 0.3.8-2): FAILED
> |The following constraints cannot be satisfied:
> |  soundkonverter-amarok (= 0.3.8-2) depends on libqt0-ruby1.8 {NOT AVAILABLE}

> This is bound to go anyways - at latest when amarok goes amarok2, so let
> us just kill it now.

Well, soundkonverter-amarok is not alone: there's also the "soundkonverter"
binary package, which seems it would do just fine. Can you file an RC bug
with the same comment as with taskjuggler?

> |lurker (= 2.1-13): FAILED
> |The following constraints cannot be satisfied:
> |  lurker (= 2.1-13) depends on libmimelib1c2a (>= 4:3.5.9) {NOT AVAILABLE}

> This is the only one I feel a bit sorry for. The debian maintainer have
> been working hard and is still working towards providing a mimelib he
> can use for lurker. I hope for it to come one day soon, but it will need
> a NEW roundtrip.

I'll leave libmimelib1c2a/4:3.5.9-5 around in testing, so it won't be
necessary to remove it. If there's a reason that won't work, please let
me know.

> |libqt-perl (= 3.008-4): FAILED
> |The following constraints cannot be satisfied:
> |  libqt-perl (= 3.008-4) depends on libsmokeqt1 (>= 4:3.5.10) {NOT AVAILABLE}

> Won't be fixed until after the summer, remove for now. Maintainer
> aware.

Well, the problem is that libqt-perl has reverse dependencies. In
particular, debian-edu-install. We need a solution for that...

> |libtse3-0.3.1c2a (= 0.3.1-4.2): FAILED
> |The following constraints cannot be satisfied:
> |  libtse3-0.3.1c2a (= 0.3.1-4.2) depends on artsbuilder (>= 4:3.5.9) {NOT AVAILABLE}

> Somehow we have missed this in the past. A rc bug have been filed about
> it since april 19 without any maintainer reaction.
> doesn't have much rdepends
> Last maintainer upload in 2005 - and last upload (NMU) was apparantly done in
> a unclean environment where it picked up half of kde.

> binNMU it and get rid of the kde dependencies.

Ah, brilliant, scheduled. I'll file a bug about non-reproducability,
though.

> |Plus the compiz-kde issue (ties KDE4 to GNOME 2.26; we'll have to figure
> |that out), and the exiv2 transition, which is a prerequisite.

> I guess breaking compiz-kde in testing temporarily is acceptable

Okay.

I'll look at the involved/left RC bugs later. About this one:

> |force kdegraphics/4:4.2.2-2

> I can't see any rc bugs on kdegraphics?  (except the one regarding
> stable, which applies to testing, but not to unstable, as the unstable
> one doesn't embed a copy of xpdf)

This was #527544; the britney I used for this test did not know about
the fix yet.

> Bottom line: We need to move forward one way or another. Either by using
> the quite good slot we seem to have now - or alternatively by saying
> "this is not it" and just continue development looking back on the
> process in a couple of months. 
> You now have my full attention 

I'll try that this can be our spot. I still need an ACK/whatever on the
BTS from the taskjuggler and soundkonverter maintainers, and we need a
solution about libqt-perl. Leaving libsmokeqt1 around in testing *could*
be an option, would that work?

> Biggest issue is a few missing builds, especially of qt4-x11 on s390 and
> ia64 and hppa. (s390 seems to be running out of memory, bastian blank
> aware, it keeps falling down the queue on hppa, I don't know who to
> contact about that)

Well, we really can't go without such a deep dep as qt4-x11, so we'll
have to figure this one out. Stay tuned.

Cheers,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai




More information about the pkg-kde-talk mailing list