Re: Preparing linux-2.6 2.6.18-1
On Fri, Sep 22, 2006 at 03:25:12AM -0700, Steve Langasek wrote:
> [Dropping -release from cc anyway; there's no possible reason this needs to
> be cross-posted to 4 lists]
>
> On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote:
> > On Thu, Sep 21, 2006 at 02:58:31AM -0500, Bill Allombert wrote:
> > > On Thu, Sep 21, 2006 at 08:52:15AM +0200, Sven Luther wrote:
> > > > There won't be any GR, there will be a new pet proposal until forever, and
> > > > endless discussions as we start recalling the DPL, and bashing on the
> > > > secretary and what not.
>
> > > In the absence of GR, the current situation is that sourceless
> > > firmwares are not allowed in main. This is the reason the RM
> > > proposed this GR in the first place.
>
> > The current consensus is that it is well among the power of the RMs to
> > ignore a number of bugs for the sarge release, including this one.
>
> I see no evidence that there is a consensus on this point. Since it's the
> RMs who have to make this decision to ignore these bugs, you're not going to
> get very far if the RMs don't actually feel empowered to make this decision
> on their own.
Yeah, badly worded. Let's say that it could be interpreted as if you have the
right to it, but as you said, you don't feel like going that way.
> > > Re-adding them at this stage
> > > 1) is against the current social contract
>
> > Yes, but then so is shipping the firmware actually still in main,
>
> So two bugs is better than one?
Yes, because re-adding the drivers which used to be pruned, allow a category
of users to install, which they did not previously. Thus, your arithmetic is
wrong, because you don't count the "can't install" bug, and if you do, it
sorts out evenly, especially if you take in account that we put non-free
software and users equally in the SC.
> > and i guess one could evoke the "won't discriminate" clause of the
> > SC/DFSG,
>
> <sigh> That's not what the DFSG says.
No, but it certainly is in the spirit of it ? Why should we discriminate
against users of non-free firmware that was decided to be removed in a distant
past, over users of non-free firmware which we decide not to remove today ?
> > Now, as said, this is a step back to better jump, and the real solution on
> > this is to follow on with what has been done (by upstream) on the qlogic
> > drivers, whose firmware is actually already in non-free, even though d-i
> > doesn't support it yet. This is an upstream work, and as thus will take time
> > to come to debian, but we, the debian kernel team (or at least me and
> > Frederik) take the engagement to work on this during etch+1 devel cycle.
>
> If it is the consensus of the project that sourceless firmware doesn't
> belong in main, this is a conscious regression in DFSG-compliance relative
Can you quantify it ? How many such firmwares ? how many lines of code ? How
many users of affected hardware ?
> to sarge. I don't think that's acceptable. We obviously do have the means
> to remove this particular subset of non-free firmware from main (technically
But we don't have the mean to support the users of said non-free firmwares.
> imperfect though it may be), and of the firmware that was removed for sarge
> the only one that was important enough to get me glared at personally was
> qla2xxx -- so what are these other already-removed firmwares that are so
> important to have re-added now? (I did ask for a list, which no one has
> provided yet; I can't find the pruning script in the kernel team's svn
> repo, or I would look it up myself.)
http://svn.debian.org/wsvn/kernel/dists/trunk/scripts/prune-non-free?op=file&rev=0&sc=0
Already pasted here the last time someone asked (was you maybe even ?). The
complete list is :
drivers/net/acenic.c
drivers/net/acenic.h
drivers/net/acenic_firmware.h
drivers/net/dgrs.c
drivers/net/dgrs.h
drivers/net/dgrs_es4h.h
drivers/net/dgrs_plx9060.h
drivers/net/dgrs_i82596.h
drivers/net/dgrs_ether.h
drivers/net/dgrs_asstruct.h
drivers/net/dgrs_bcomm.h
drivers/net/dgrs_firmware.c
drivers/net/tokenring/smctr.c
drivers/net/tokenring/smctr.h
drivers/net/tokenring/smctr_firmware.h
drivers/media/video/dabusb.c
drivers/media/video/dabusb.h
drivers/media/video/dabfirmware.h
drivers/usb/misc/emi62.c
drivers/usb/misc/emi62_fw_m.h
drivers/usb/misc/emi62_fw_s.h
drivers/usb/serial/keyspan.c
drivers/usb/serial/keyspan.h
-drivers/usb/serial/usb-serial.h
drivers/usb/serial/keyspan_mpr_fw.h
drivers/usb/serial/keyspan_usa18x_fw.h
drivers/usb/serial/keyspan_usa19_fw.h
drivers/usb/serial/keyspan_usa19qi_fw.h
drivers/usb/serial/keyspan_usa19qw_fw.h
drivers/usb/serial/keyspan_usa19w_fw.h
drivers/usb/serial/keyspan_usa28_fw.h
drivers/usb/serial/keyspan_usa28x_fw.h
drivers/usb/serial/keyspan_usa28xa_fw.h
drivers/usb/serial/keyspan_usa28xb_fw.h
drivers/usb/serial/keyspan_usa49w_fw.h
drivers/usb/serial/keyspan_usa49wlc_fw.h
drivers/usb/serial/keyspan_usa26msg.h
drivers/usb/serial/keyspan_usa28msg.h
drivers/usb/serial/keyspan_usa49msg.h
drivers/usb/serial/keyspan_usa90msg.h
qlogic stuff is not even mentioned here, so if even the come back of those
firmwares above is offset by the removal of the qlogic stuff, and there are at
least 3 network driver which i consider essential for installation using the
netboot media. The rest are three usb thingies, and could be arguably useful,
for debugging on a serial console on a powermac for example. No idea what the
emi stuff is, or the dabusb, but i am clearly certain that if you where to
rate the importance of these three drivers compared to the qlogic one, we
would still gain here.
Also another point, the prune-non-free thing was written in ruby by Andres,
and since he left, i don't know if there is much ruby skill left, i personally
don't know nothing about ruby.
> > But due to everyone (including you), trying to pull the glory to themselves,
> > and proposing their pet GR to muddle the issue, without any respect for the
> > GRs proposed previously, and because of the loophole in the constitution,
>
> I don't believe there is any loophole there. The constitution defines what
> it means for an amendment to be accepted, and it does not apply to
> additional related resolution proposals, it only applies to amendments to a
> resolution that are *accepted by the proposer*. Which means independent
I have seen this argument, and i have seen it mentioned as counter argument
that it doesn't say *by the proposer*, so could mean anything.
> draft proposals are not supposed to reset the minimum discussion period.
> (FWIW, it took a hint from AJ for me to recognize that this is what the
> constitution actually says, but Ian Jackson -- original author of the
> constitution -- has recently confirmed this understanding.)
Yeah, maybe, in the meantime, we have had what, near to 10 different GRs,
amendments, proposals, whatever about the same issue, and everyone is so bored
about the issue that no real discussion is going on, including on merging
similar proposals or anything.
> Anyway, I think we'd be able to get to the point of holding a vote much
> sooner if we weren't having distracting side discussions like this one. I
> know it's sucking up time that *I* would rather be spending examining the
> various resolutions that are already out there.
2.6.18 upload to unstable is due since 2 days, the kernel was frozen in
august, it is past time to play GR-filibustering games.
> > So, given the defaillance of the GR system, there is no point in worrying
> > about the vote or not, and always remember, that debian was at the base, and
> > still is to a mesure, a system where those who do the work get to do the
> > decision, so you know what you have to do if you want those firmwares not to
> > be in main :)
>
> Well, all /I/ have to do to keep the reintroduced firmware blobs from being
> in etch is to freeze the linux-2.6 package at 2.6.17 :/
Indeed, but then you also need to backport all the fixes that the kernel team
will put in 2.6.18 to 2.6.17, fine sharing of effort. Did you not read
Frederik's GR, where the kernel team states that kernel dev ressources are
rare, which is why we request a waival of the requirement for etch, in order
to be able to work on this issue in peace for etch+1, without having to deal
with the two new GRs a week over highly emotional issues, not mentioning the
remaining bullshit that is going on beside it (RM payement, duck stuff, DPL
recall, assorted GRs for various stuff).
Friendly,
Sven Luther
Reply to: