Re: Final polishing of the KDE 3.3 transition
Hi,
just two comments by me:
* Adeodato Simó (asp16@alu.ua.es) [050102 20:35]:
> (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.
Just uploading.
> (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
4. doesn't work, because the current bugs implementation doesn't do bug
version tracking. For that reason, I personally tend to prefer to lie
about the status (with setting sarge-ignore), because if everything
would work well, britney would know that we in reality lower the number
of RC bugs by this transition. However, because britney can't know
currently, we have to shield light on it by other means. However, I
don't really mind to lower them to important currently - but it need of
course to be documented why we do it.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: