Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Saturday October 25 2014, @02:41PM   Printer-friendly
from the whining-is-not-efficacious dept.

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?

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by Marand on Saturday October 25 2014, @04:33PM

    by Marand (1081) on Saturday October 25 2014, @04:33PM (#109975) Journal

    I use wine to play some games on my Debian system. I just updated wine a few minutes ago, and ran into this bug. I don't care if there's a patch. It's useless to me if I can't immediately pull it in as an update.

    This will sound harsh, but it's only useless to you because you're choosing to be useless.

    You've chosen to use the testing distro, and now you're upset that a bug is affecting you. That's like using the Windows 10 preview that's out and then complaining that you found a bug in it. If you're not willing to accept that there will be problems like this and either wait for a fix or try to find a workaround, then you clearly installed Debian from the wrong repository.

    You have options you can choose to deal with the problem:

    1. Don't use the testing repository if you can't handle occasional temporary breakage. It's called "testing" for a reason. Stick to the stable release and use the backports repository.
    2. Wait for the update.
    3. Mix repositories. You can often cherry pick pieces out of stable or unstable as needed. If you really need wine to not change abruptly, start using it out of stable perhaps.
    4. Try using the repository from winehq.org. It says it's for sid (unstable) but outside of a freeze unstable and testing don't differ much.
    5. Compile it from source. Wine is dead simple to compile. Getting games to work in wine is more difficult than compiling wine itself
    6. Buy CrossOver.

    I personally like option #5 because it's easy to keep multiple versions of wine around if needed for wider compatibility, plus I can always have the newest version when I want it.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Saturday October 25 2014, @05:07PM

    by Anonymous Coward on Saturday October 25 2014, @05:07PM (#109990)

    This isn't an obscure bug, though. This is Wine not starting up at all! It's obvious with even the most minimal level of testing. This is as bad as the JVM not starting up, or the Python interpreter not starting. This bug makes it so that thousands of other programs now can't be run. It's a very serious bug.

    • (Score: 2) by Marand on Sunday October 26 2014, @04:37AM

      by Marand (1081) on Sunday October 26 2014, @04:37AM (#110167) Journal

      This isn't an obscure bug, though. This is Wine not starting up at all! It's obvious with even the most minimal level of testing. This is as bad as the JVM not starting up, or the Python interpreter not starting. This bug makes it so that thousands of other programs now can't be run. It's a very serious bug.

      Why does it matter that it's obscure or not? It's a bug, it's testing, it will get fixed in time. This isn't the first time something major has broken in testing, and it won't be the last. I switched from stable to testing in 2005 and have been using it since, and while uncommon, this sort of thing does occasionally happen. Sometimes it's dependency screw-ups that make a package remove stuff it shouldn't, other times it's packaging errors that just break a program, but they get ironed out, especially for the bigger packages. One example that stands out in my memory is Compiz, because it used to break quite often between updates.

      I'm not saying the bug isn't a bad one, but it's not a world-ending problem. Hell, the previous version (1.6.2-8) is still in the repository so it's not like you're stuck with the bad one. The first response to "oh crap wine broke" should have been "I better downgrade to the last working version" rather than "I will complain on SN about this".

      These sorts of things are part of using the testing repo, though I'll admit it's easy to forget that considering how solid the testing repo usually is. I started using it as a rolling-release Debian on my main system because the major problems are so rare, but occasionally something like this happens and I just work around it for a few days.

      Also, not directly relevant, but wine breakage vs python breakage isn't even remotely comparable, considering Python and Perl are actually needed for parts of the system but wine isn't. The JVM comparison is closer, though.