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

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

          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

        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

        So please, just let us know what to do about this.


  -- 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: