Re: Minidisk support (was: Installation Question)
First of all, thank you very much for your lengthy reply. I am honored
that you took the time to explain so many things. However, I believe that
you have some misconceptions as well.
> (No need to CC me; I read the list; see the Debian mailing list policy.)
Here is the exact wording from the mailing list policy:
When replying to messages on the mailing list, do not send a carbon copy (CC)
to the original poster unless they explicitly request to be copied.
Strictly speaking, I did not do that. I am subscribed to the list; and
whenever a post is made, I get a copy in my private e-mail. My private
e-mail sees the e-mail as coming from the poster, not from the list.
As viewed by my e-mail system, I was replying to a private e-mail from you.
It was the list that I added to the CC, for the benefit of others.
Nevertheless, I acknowledge that the net result is the same. In the future,
I will try to remember to change the TO field from the poster's address to
the list address instead of adding the list address to the CC list, unless
I know that the poster is not subscribed to the list or he explicitly
requested a CC.
By the way, there's another item on the mailing list policy that may interest
you:
If you want to complain to someone who sent you a carbon copy
when you did not ask for it, do it privately.
> please don't hijack an existing thread for an unrelated
> issue; next time, please just start a new thread instead.
Well, to you it may seem unrelated; but to the way I was thinking at the
time, it was related. User A was asking if fix X was going to be included
in the next update and user B (me) was chiming in to ask if fix Y
was going to be included as well. I defer to your judgment on this matter,
but please keep things in perspective. This list has a very low posting
rate. Here we are in the middle of December, and this is the first
legitimate thread, not counting spam, that has been posted this month.
I wouldn't be surprised if it's the only thread at the end of the month
(except for the fact that you forced a new thread).
I doubt that people are going to have trouble keeping everything straight.
"Hijack" is a strong word. When I think of hijack, I think of the
terrorists who hijacked those planes and flew them into the World Trade
Center. Hijacking is criminal activity. If you think a reply belongs in
a new thread, please just start one yourself in the reply.
> You are mixing two different things in this mail:
> - the next stable release (Squeeze)
> - the next update (point release) for the existing stable release (Lenny)
>
> The rules, limitations and methods for getting changes included are
> completely different for them, and you should clearly separate between
> them.
OK, maybe I don't know all of the Debian-internal-use-only terminology.
Apparently, what I should have said is
"stable point release" instead of "stable release update". By "stable
release update", I meant an update to the stable release, that is, an
update to Lenny. I did not mean "Squeeze becoming the stable release".
Sorry for the confusion.
> The people to ask are the kernel team.
I *did* ask the kernel team. Debian bug report 550898 was reported against
package linux-image-2.6.26-2-s390x. The maintainer for package
linux-image-2.6.26-2-s390x is
Debian Kernel Team <debian-kernel@lists.debian.org>.
Here is part of what I said in my last post:
Since upstream development has accepted this as a bug and has agreed to
provide a fix in the next merge window, I respectfully request that this
patch be included in the next stable release of Debian for s390
(6.0.0 -- Squeeze). If you could include it in the next update of the stable
release (5.0.4 -- Lenny), that would be good too. In the meantime I will
need to build a custom kernel with every security update that hits the kernel,
which I don't like to have to do.
As I read over this again, I now realize that I used internally inconsistent
terminology, which may have added to the confusion. Nevertheless, I did
mention both Squeeze and Lenny as releases that I would like to see updated.
But there was no response.
> There is no difference between regular and D-I kernels, especially not for
> the next stable release. D-I merely repackages the regular kernel into
> udebs it does not build its own kernels.
> So, any change included in the regular kernels almost automatically gets
> included in the installer (except when it requires additional new kernel
> modules to be included, which is not the case here)
Hmm. Starting with the top directory of the Debian archive,
dists/squeeze/main/installer-s390/current
is a symbolic link to
../../../lenny/main/installer-s390/current
so right now the boot-up files that I use to install, which are
dists/squeeze/main/installer-s390/current/images/generic/kernel.debian
dists/squeeze/main/installer-s390/current/images/generic/initrd.debian
dists/squeeze/main/installer-s390/current/images/generic/parmfile.debian
etc. are all pointing to the Lenny version of the Debian installer.
When the installer is used, either to install or in a rescue mode,
this is the kernel that is running. It may *install* a newer kernel,
when it is actually performing an install; but the kernel that is
*running* comes from the image files listed above.
> For stable updates it is a bit different as not every point release
> includes an update of the Installer, and even if the installer is updated,
> it does not necessarily include a kernel update.
And that's why I asked. I actually was trying to accomplish two things:
(1) I thought that the primary maintainer for the s390 version of the
Debian installer would be in a position to know whether the next point
release (though I didn't call it that) was going to include an s390-specific
update to something as basic as a DASD driver, and (2) If you didn't
know about the fix I wanted to make you were aware of it so that you would
include the update to the installer kernel in the next point release.
> The kernel team policy is to only include patches that already
> have been accepted upstream or look certain to get included upstream very
> soon.
I figured as much. And that's why I mentioned that upstream had accepted it.
> For stable updates added criteria are:
> - it must fix an important *bug* (affecting a significant number of users),
> or
> - it must be an enhancement that is very important to a significant number
> of users *and* has no risk of introducing regressions.
Well, it's definitely a bug. But whether or not it affects a "significant"
number of users is another story. This bug has been around since day 1 of
the driver. And I'm apparently the first one to find it. So claiming that
it affects a significant number of users would be a hard sell.
> This patch is IMO more an enhancement than a bug fix, so I'm not certain it
> qualifies for a stable update.
I disagree. It's definitely a bug, not an enhancement. Nowhere is it
documented that DIAG requires a read/write minidisk. And the ECKD driver and
the FBA driver support read-only minidisks (as defined by CP). Claiming it
to be an enhancement is going to be a hard sell. But with regard to whether
or not it qualifies for a stable point release update, it's probably moot.
I've already conceded that it doesn't affect a significant number
of users (at least not yet); so I guess it doesn't qualify.
>> But since stable Debian releases
>> tend to go with even numbered kernel releases, the earliest upstream
>
> That is a totally random deduction based on nothing else than coincidence
> for the last few releases. There is no difference between odd and even
> upstream releases, so no reason for Debian to prefer even ones. The choice
> of kernel version is mostly a timing issue (when is the upstream release
> relative to Debian's freeze date) and possibly what kernel other
> distributions use for their releases (so we can profit from long term
> maintenance of that kernel release).
I guess I was thinking of the middle number instead of the last number
(i.e. 2.5.xx vs. 2.6.xx). You're right. Never mind that point.
The rest of the post is mostly about suggestions for how to get this into
the 2.6.32 vs the 2.6.33 kernel. Thank you for the suggestions. I'll
keep this information for future reference. But since nobody seems to care
but me, I'm not sure it's worth it. Again, thanks for taking the time to
post such a lengthy and detailed reply. I appreciate it.
I am working on a backport of the official fix that will apply to the 2.6.26
kernel. As published, it does not apply due to changes in the way kernel
messages are issued between 2.6.26 and 2.6.33. I am hampered by my limited
knowledge of C. But necessity is the mother of invention. I will publish
my results when I'm finished, and if anybody other than me cares, they can
download it and build their own custom kernel. As to whether this fix makes
it into Squeeze or not, I guess that depends on which kernel Squeeze chooses.
If they choose a kernel prior to 2.6.33, I will try to publish a backport
for whichever kernel Squeeze chooses as well.
If the kernel team had simply stated their policy for including
updates in a stable point release in a reply to Debian bug report 550898,
and telling me it did not qualify based on those criteria,
they would have saved both of us a lot of time.
Reply to: