Final polishing of the KDE 3.3 transition
Hi all!
The gcc-3.4/libunwind transition having happened on Dec 31st, KDE 3.3
is mostly ready to enter sarge. In this mail, I will make a summary of
the last issues that need to be addressed:
(a) #266478, the dummy bug "new kdelibs should not enter testing
alone", should be closed now. If some RM mails to -done, that
would be nice. (But see (d) below - I have not already closed
it since I wanted some feedback first.)
(b) kdeedu is missing a mipsel build. This is a timeout issue, which
needs to be increased. kdeedu was retried on mipsel on Dec 25th,
but with the timeout unchanged, so Andreas Barth offered to do a
porter build+upload. Yesterday, he told me he was starting the
build with a 1500 min. timeout.
This is the biggest stopper atm, aiui.
(c) Unless some RM objects, the latest security bugs won't get fixed
before the transition, and uploads to address them will be done
shortly after the transition with urgency=high.
I talked to Andreas about this too, and he agreed to it since
all the vulnerabilities are present in the current sarge
packages as well.
We now request for instructions about how to proceed so that the
affected bugs are not included in the RC bug count. One of:
1. <vorlon> those security bugs will have to be temporarily
downgraded
2. <vorlon> the only other way is to use force hints, and
using force hints would override the safety we were trying
to put in place.
3. <calc> you could set a temporary sarge-ignore tag?
4. <dato> or temporaly leave all of them as +sarge only, right?
(but: <vorlon> I think I prefer to lie about the severity
rather than lie about the tags; Kamion may have a different
opinion as a bugmaster.)
The bugs in question are these (all of them are tagged sarge,sid):
#285128: kdelibs: CAN-2004-1165: FTP command injection bug
#286516: kdebase: CAN-2004-1158: Konqueror Window Injection Vuln.
#286521: kdelibs: CAN-2004-1145: Konqueror Java Vulnerability
(d) Given the number of packges that are stalled by kdelibs [1] and
not covered by this transition (i.e., not in the hands of the
KDE packagers), I expressed two concerns back in November [last
section of 2].
[1] http://bjorn.haxx.se/debian/testing.pl?waiting=kdelibs
[2]http://lists.debian.org/debian-release/2004/11/msg00154.html
The first concern, "one has really to check that the existing
version in sarge will work correctly in a KDE 3.3 environment,
as newer versions may or may not make sarge", can be considered
solved: we received positive feedback from users that had
upgraded their KDE to 3.3 in sarge systems.
As for the second concern, I'm only mildly drawing some
attention from RMs to it: kdelibs entering sarge will mean a
bunch of packages with *big* differences migrating, so I always
thought that the Release Team would prefer these migrations to
happen smoothly, and semi-controlled (plus what I say in the
mail), and the only scheme I could came up with was the mass
bug-filing.
So please, just let us know what to do about this.
Cheers.
-- dato, on behalf of the KDE Packaging Team
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: isan - cutlery favours
The first step on the road to wisdom is the admission of ignorance. The
second step is realizing that you don't have to blab it to the world.
Reply to: