Wine 1.2 Stable is released

Yes, I'm well aware, give me a couple days to make sure it's building fine and we'll start the SRU process

Now waiting in lucid-proposed unapproved queue

Needs ubuntu-sru subscribed

Needs approval from ubuntu-sru

Needs test case

Needs rationale for update to new upstream version

As far as test cases are concerned, basically any Wine app will suffice.

Wine went into code freeze shortly after Lucid release, so nearly every change between Lucid's prerelease version of Wine and 1.2 final was part of that conservative release process. In particular, Wine developers fixed numerous regressions from 1.0 and made many new applications work, so any of these would be a solid use case for upgrading to 1.2 as they would be broken in the shipped Lucid Wine.

Although, if you must pick an App that is now working and wasn't before, I suggest Starcraft 2 ;)

Hold off on committing the proposed package, just found some minor inconsistencies due to its ppa lineage -- I'll clean those up.

This is stretching the SRU policy quite a bit, but the overall nature of changes look ok, so for the sake of LTS, let's digest this a while in -proposed. Verification should include testing various Windows applications which ran before.

There is one thing in the debdiff which looks potentially troublesome:

--- wine1.2-1.1.42/debian/wine1.2.postinst 2010-08-06 05:48:17.000000000 +0100
+++ wine1.2-1.2/debian/wine1.2.postinst 2010-08-06 05:48:19.000000000 +0100
@@ -31,7 +31,7 @@
                 ;;
         esac
         # Reload the sysctl file
- invoke-rc.d procps start || true
+ start procps || true

I know that this actually fixes the procps restart, but in environments which use policy-rc.d to disable init scripts this would suddenly start to run one. Since it's "only" procps, it should not cause too much trouble (if /proc is not available, then you'd just go through the || true part), but at least I wanted to point it out. Would it be prudent to revert that for the SRU?

I'm not too familiar with the implications of invoke-rc.d vs start, but I changed it to start on direct command from Scott James Remnant.

Wine developer here. FWIW, here's some of the big changes between 1.1.42 and 1.2:
more complete 64/32 bit wine sharing, better fonts on LCD's (fontconfig taken from user settings), better support for .Net apps, long standing opening urls in browser bug fixed, fixes for Microsoft Office 2007, uTorrent, AutoCAD, Fallout 3, Starcraft 2

also, full release notes:
http://www.winehq.org/announce/1.1.43
http://www.winehq.org/announce/1.1.44
http://www.winehq.org/announce/1.2-rc1
http://www.winehq.org/announce/1.2-rc2
http://www.winehq.org/announce/1.2-rc3
http://www.winehq.org/announce/1.2-rc4
http://www.winehq.org/announce/1.2-rc5
http://www.winehq.org/announce/1.2-rc6
http://www.winehq.org/announce/1.2-rc7

On Fri, Aug 06, 2010 at 09:59:53AM -0000, Scott Ritchie wrote:
> I'm not too familiar with the implications of invoke-rc.d vs start, but
> I changed it to start on direct command from Scott James Remnant.

I consider this an SRU reject matter. start *is not a policy compliant
maintainer script interface*. Packages *must* use invoke-rc.d instead of
calling start directly, regardless of whether they use upstart jobs, until a
new policy can be determined.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve Langasek [2010-08-06 16:13 -0000]:
> I consider this an SRU reject matter. start *is not a policy compliant
> maintainer script interface*. Packages *must* use invoke-rc.d instead of
> calling start directly, regardless of whether they use upstart jobs, until a
> new policy can be determined.

I agree. Unfortunately invoke-rc.d is not patched to call "start" for
upstart scripts, i. e. it just prints a lecture and otherwise does not
do anything.

So, perhaps we should mirror what update-rc.d would do in maintainer
scripts?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

New version that reverts to invoke-rc.d posted

Waiting in lucid-proposed unapproved queue

Needs ubuntu-sru approval

Needs debdiff on bug

Accepted wine1.2 into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I have installed wine1.2 from the proposed repository and it looks good to me. I am using a few windows applications and they all work fine, some better than with the original wine version in Lucid e.g. ImgBurn window is finally not vanishing from my desktop on workspace switch since that bug was fixed in 1.2-rc4. (See: http://bugs.winehq.org/show_bug.cgi?id=10142)

For reference I've posted a call for testing at http://ubuntuforums.org/showthread.php?t=1566265

I've uploaded a new version of the -proposed package with some minor additional changes merged in from Maverick:

Build depend on unixodbc-dev (otherwise wine's odbc support gets disabled - this has generated a few bug reports)
Bump version of libstdc++6 used to system default (this shouldn't affect anything except on amd64, where the only 32 bit version is 4.4)
I also disabled the recommends for gnome-exe-thumbnailer since Lucid's gnome-exe-thumbnailer is less pretty than Maverick's (this way is consistent with the shipped wine1.2 in Lucid)

Scott,

testing of the current lucid-proposed version looks fine (both here in comment 14 and also in the forums). However, the upload you did seems to replace the one in lucid-proposed instead of adding a new revision relative to it. I'd prefer to move the current SRU to -updates and then start a new one with the new fixes; unless you consider the current -proposed version broken and don't want to see it in -updates?

Well the SRU will install an ugly gnome-exe-thumbnailer if it goes live because it's in recommends.

This isn't so bad if we can also SRU the maverick gnome-exe-thumbnailer at the same time.

By the way the newly uploaded version (but not the one currently in proposed) also fixes https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/572393

I think the best way forward here is to just replace the -proposed with the one sitting in the queue (and retest a bit) since then we don't have to worry about exe-thumbnailer inconsistency.

I've been able to install Fallout 3 without error, but it seems the actually application will not run.
I've had to install via WineFile, and attempt to play via WineFile.
Any ideas why this would be?

Please replace the one in -proposed with the last one I put in the queue. The one in -proposed recommends exe-thumbnailer, however it does not make an exception for KDE users, resulting in them getting it unnecessarily.

1.2-0ubuntu6~lucid5 accepted into lucid-proposed, please test.

1.2-0ubuntu6~lucid5 works fine for me - I tried winmerge and 2 educational apps that I have handy.

Thanks for testing, Alkis! Can anyone please test the new thumbnailer as well?

1.2-0ubuntu6~lucid5 works fine for me, too. I installed it on 4 machines. The thumbnailer also works well (though I never had a problem with the previous one either).

This bug was fixed in the package wine1.2 - 1.2-0ubuntu6~lucid5

---------------
wine1.2 (1.2-0ubuntu6~lucid5) lucid-proposed; urgency=low

  * Wine 1.2 final release for Lucid (LP: #606509)
  * Many more applications work, especially those from companies named
    after particularly cold weather events
  * debian/control: use Lucid's libstdc++6-4.4
 -- Scott Ritchie <email address hidden> Wed, 29 Sep 2010 03:10:59 -0700