On Sat, Jun 11, 2005 at 06:35:50AM +0200, Sven Luther wrote:
> On Wed, Jun 08, 2005 at 08:30:18PM +0200, Jeroen van Wolffelaar wrote:
> > (note, I'm not subscribed)
> >
> > Hi,
> >
> > kernel-source-2.4.{24,25,26} just made it into Etch -- I'm sure that was
> > not really intentional, and those can rather be removed from unstable?
> > If so, please do file a bug (one listing all three would do) on
> > ftp.debian.org.
>
> I believe there was partially such a bug report against some of those
> packages. There still are 2.4.26 apus kernels in the archive last i checked.
Yes, you did so not so long ago, meanwhile that bug already got fixed
(i.e., the removals done) -- thanks for that.
> > Second point -- would there be any easy way you can think of some
> > non-ftpmaster involving way to prevent this from happening in the
> > future? Like, making the kernel-source-2.4 and kernel-source-2.6
> > package, building kernel-source-2.{4,6}.X binary package? I do think you
> > only need one major kernel line version simultaneously, right?
>
> Yes and no. but let's sort out the metapackages thingy once the common kernel
> package is out. We need to unify the different kernel-latest thingies too, so
> this could easily be added, but it is still not enough, since having 2.6.12 in
> the archive is not a reason for immediate dropping of 2.6.11, since there is
> likely to be a transition period where it is meaningfull to provide our users
> with both, in order to more easily check newly introduced bugs or regressions.
I forgot about the planned kernel packaging changes, besides your point
of providing both does make a lot of sense, so well, I guess the answer
is simply "no, there is no such easy way".
> > If that's not possible, for whatever reason I'm sure you're much more
> > familiar with than I am, of course then it's not possible, and instead
> > removal requests can best be filed every time a transition to a new
> > minor kernel version is completed.
>
> The main problem is that usually such removal requests got processed ages
> after the request. This is changing now with the new more dynamic ftp-master
> team, but i guess a request for removal get's easily lost in the noise or
> something, not sure how you see that on your side ?
I try to do removals at least once a week, usually faster -- especially
for those that require very few consideration, like older-version
removals (as opposed to complete removals of a certain package), tend to
get processed really fast. Because removals are filed via the BTS, they
should never get lost, especially since bugs titled "RM: <package(s)>
..." on ftp.debian.org will show up in my overview of pending removal
requests (rather than only the bigger overview of all ftp.debian.org
bugs).
Thanks,
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
