A grave bug has been introduced into the "wine" package of Debian Jessie, just days before the November 5th freeze deadline. The /usr/bin/wine launch script fails with an "error: unable to find wine executable. this shouldn't happen." message.
Debian has already suffered much unrest lately over the inclusion of systemd, with threats of a fork being issued, along with the possible cancellation of the GNU/kFreeBSD port and the possible dropping of support for the SPARC architecture. After so much strife and disruption, can Debian afford to have such a serious bug affect such a critical package so soon before such a major freeze?
(Score: 1, Insightful) by Anonymous Coward on Saturday October 25 2014, @03:00PM
I don't use Debian, so I don't know much about its development process. But can somebody explain to me how a bug like this could even happen?
How can a package be updated and made available to the public with such an obvious and blatant flaw?
I mean, did the package maintainer not even try to install it and then use it, even just once?
Given how it fails in such a basic way, it appears to me that absolutely no testing whatsoever was done! That's unbelievable, especially for a distro like Debian, that has generally had a good reputation.
(Score: 1) by Entropy on Saturday October 25 2014, @03:20PM
It probably didn't happen on the test system(s). It's quite possible for a bug to manifest differently or not at all depending on what else is going on with the system in question. I doubt it was as egregious as "I never tried to run wine, it doesn't work?"
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @03:32PM
I don't think that's true in this case. Look at the patch that supposedly fixes it. The script contains some broken paths. It should fail on any test system.
If testing was actually done, and it didn't fail, then something is seriously, seriously broken with the test system. That in itself is another inexcusable problem.
So not only is the package itself fucked up, but now the test system hasn't been properly configured or maintained, either?
Somebody has seriously screwed up here, in multiple ways, with horrible timing.
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @06:33PM
To err is human... There are no inexcusable problems.
(Score: 2) by HiThere on Saturday October 25 2014, @06:52PM
No. But sometime strings of errors smell of intent. This can be a mistake, but it can also be a mistake to ignore the odor.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by Bot on Saturday October 25 2014, @04:21PM
Given that the executable works and it is a case of borked launcher script because some paths have changed, it is very likely that the packager built the new version and ran it directly. IIRC Debian has helper scripts that prepare chroots for packaging purposes.
I think we are throwing out the baby and his older brother and the dog with the bathwater.
Account abandoned.
(Score: 2) by DECbot on Sunday October 26 2014, @07:54PM
With systemd, they're all integrated tightly into the bathwater, so how could you tell what you're throwing out? I guess the binary logs might help. Of course those depend on the bathwater too.
cats~$ sudo chown -R us /home/base
(Score: 2) by sjames on Saturday October 25 2014, @09:28PM
Really, it didn't. This is the testing distro, not stable.
It is not preferred that this big a package problem crop up this close to a freeze, but it isn't fair to compare it to something released as stable. That has not happened.
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @11:17PM
Unlike e.g. Ubuntu, who puts the release date in their version number (and is compelled to meet that shipping date), Debian ships when the code is ready.
...and before they declare it ready, they squash all known bugs. [archive.org]
-- gewg_