On 2013-05-06 00:33, Ben Hutchings wrote:
On Mon, 2013-05-06 at 00:01 -0400, Filipus Klutiero wrote:
severity 706659 normal
thanks
On 2013-05-05 21:29, Ben Hutchings wrote:
On Sun, 2013-05-05 at 20:57 -0400, Filipus Klutiero wrote:
[...]
Previously, you wrote:
Therefore, the prompt is misleading and may cause the user to install
unneeded software or change hardware without a strong reason.
There are very few cases where the current statement is incorrect. In
your example, the Realtek PHY firmware patch is needed because (if I
understand correctly) the ROM firmware is incompatible with a lot of
other Ethernet devices and won't establish a link. Even though it may
not affect the specific cable and switch you were using during
installation, you will not want to find out about this bug when you plug
the machine in somewhere else! (And I don't want to see this bug being
reported against the driver.)
The proper way to avoid such reports would be to warn admins if a
buggy firmware is detected (and ideally offering an update).
It is detected.
What I meant is that the purpose of check-missing-firmware is to offer firmware
which may enhance the target. Its purpose is not to detect buggy firmware and
warn the admin, accessorily offering firmware updates to solve. If we want to
avoid bogus bug reports against drivers, fixed firmware surely helps, but if
the only firmware fixing the issue has downsides, that only solves part of the
cases. We should also inform admins who prefer the original firmware of what
problems that firmware will cause.
Even if there are few cases where the current statement is incorrect,
this is a bug. If you're confident that there are few cases, feel free
to set severity to minor, but I have 2 personal PCs, and both have a
device where the current formulation is inappropriate.
I don't know much about this specific example, but I'm skeptical about
Realtek shipping a firmware which fails in "a lot" of scenarios, and
continuing to pre-install that buggy firmware today.
If the firmware is loaded from ROM, as I suspect it is, then they can't
change it except by re-spinning the chip which is extremely expensive -
or, as they do, by patching it from the driver code.
Hum, thanks
I assume there are several different bugs fixed by the various different
firmware patches for each chip.
That's quite possible. Surely having a changelog or any explanation at all of
the firmware's interest would be nice. But Debian comes with thousands of bugs.
I think there should be a very good reason to prompt or warn about a bug (or
bugs) when installing at default priority.
[...]
Radeon cards are good examples of devices which are improved by
firmware without being unusable without.
The current AMD GPUs cannot be used without firmware, except through the
userland VESA driver which has appalling performance and doesn't support
the native resolution of most displays (or any widescreen displays,
AFAIK). We definitely should be alerting users that this hardware does
need firmware to work properly.
OK, I was thinking about older GPUs such as Radeon HD 5650M, which can
use the radeon driver without installing non-free firmware. Anyway,
both of these cases are good examples; even in your case, the current
prompt says firmware is needed for the devices to operate. "Operate"
and "work properly" are not the same. And even "work properly" would
not be quite true - if vesa works bug-free, I'd say the device can
"work properly". Maybe not "work well".
The VESA driver does its job OK, but the system as a whole is buggy if
it can't drive the connected displays at native resolution or use the
actual GPU.
We need to look at this in functional terms. If an algorithmic breakthrough is
achieved tomorrow allowing CPUs to do anything GPUs do better, then we don't
need to use GPUs anymore. The fact that systems would keep unused GPUs might be
suboptimal, but that doesn't make these imaginary systems buggy. Similarly, if
a resolution other than a native resolution doesn't cause problems other than
making the user's experience suboptimal, we have a problem but not a bug.
Even if we had a bug, we wouldn't necessarily have one which prevents the
device from operating. My problem is really with excessive alarming of admins.
I don't have problems with warning or prompting, as long as this doesn't
mislead admins. In fact, such information can be useful.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
