[pkg-wine-party] Debian wine package maintenance / debian bug 479659

[Austin English]

On Sun, Nov 14, 2010 at 1:32 PM, Stephen Kitt <lists at sk2.org> wrote:
> Hi Austin,
>
> On Sat, 13 Nov 2010 15:22:41 -0800, Austin English <austinenglish at gmail.com>
> wrote:
>> I've seen quite a few people asking for Wine on Debian recently. I've
>> read up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479659, as
>> well as a few other pages. I got your git repository from
>> http://pkg-wine.alioth.debian.org/, and after a bit of setup, got it
>> to compile the 1.1.33 debs.
>>
>> I'd like to take over maintaining the Debian Wine packages, presumably
>> with your mentoring/sponsoring.
>
> Please see also the various bugs regarding new upstream versions of Wine
> (http://bugs.debian.org/557783 and http://bugs.debian.org/585409), others
> have been working behind the scenes too. Of course the more the merrier, and
> since you're involved in the upstream Wine community we're better off with
> you on board!

Read them now, thanks.

>> If so, we can get started and get debian wine up to date :-).
>
> I've got the basics up on http://www.sk2.org/wine, up to version 1.2. I
> discussed the situation with Ove a while back, just after Squeeze froze, and
> so far the plan is as follows:
> 1. Get wine-gecko into Debian; this involves:
> 1a. Update the binutils and gcc packages for MinGW-w64.
> 1b. Update the version of MinGW-w64.
> 2. Update wine and wine-unstable.

Looks good. Gecko isn't a showstopper, we can easily patch wine to not
prompt on startup if gecko is missing, and have users get it from
contrib until we can properly package it.

That said, since Squeeze is in freeze and will be for a while, that
may be enough time for mingw64 to get ready.

> It would also be interesting to get wine-mono in...

Yes. This is pretty easy, actually, since it doesn't need mingw64.
I've successfully built the tarball on my Ubuntu box, I don't see any
reason why Debian would be much harder. I'll take a look at it
shortly.

> (1a) is currently in progress, see http://bugs.debian.org/602996 and
> http://bugs.debian.org/602997. The current packages are in git on alioth, see
> http://git.debian.org/?p=collab-maint/gcc-mingw-w64.git and
> http://git.debian.org/?p=collab-maint/binutils-mingw-w64.git. This also
> involves discussions with Ron, the maintainer of the mingw32 toolchain in
> Debian, which are ongoing. Note too that the gcc package is currently blocked
> by a bug in gcc-4.5-source.
>
> (1b) is also in progress, see http://bugs.debian.org/594371; I haven't
> uploaded my packaging of mingw-w64 yet. I'll hopefully find time to do it
> this week.
>
> (1) itself involves small changes compared to my packages on
> http://www.sk2.org/wine, to build with newer versions of MinGW-w64; I've
> already made the changes but haven't uploaded them yet.
>
> (2) is fairly straightforward based on Ove's packages. I do know though that
> Ove intended to update the packaging somewhat, but there wasn't much hurry
> given (1).

Right.

>> A few starting questions:
>> Do I need a 64-bit debian machine to make the build, or will it be
>> enough to make the 32-bit packages and have the build bots take care
>> of 64 bit.
>
> If you want to get the support for 64-bit Windows working, you'll need a
> 64-bit machine. I haven't started work on this at all yet.

Personally, I don't think it's worth the effort at this time. A 32-bit
build of Wine on a 64-bit OS is what most users want. 64-bit windows
application support at this point in Wine is still in an early beta
stage, many things should work, but still quite a few bugs.

Once wine/wine-unstable are updated and gecko is done, along with
wine-mono, I'll take a look. It shouldn't be very hard, just time/disk
space intensive. See also http://wiki.winehq.org/Wine64ForPackagers.

>> Same for old debian versions, will the build bots take care of this?
>
> Packaging work for Debian main usually targets unstable or experimental.
> Since wine-gecko needs gcc 4.5, which is currently only in experimental, it
> has to target experimental too; if wine's dependency on wine-gecko is strong
> (as Ove wishes it to be), wine will have to target experimental also. I guess
> once Squeeze releases gcc 4.5 will move to unstable and everything else can
> follow.
>
> This complicates the situation with regards to backports, which have to be
> managed explicitly in any case.

Okay.

>> Should my first 'real' package be 1.1.34, or 1.2?
>
> Historically Ove uploaded all versions of Wine successively, based on the
> idea that a specific version of Wine may be useful to someone and hence it
> is useful to have them all on http://snapshot.debian.org. Given how old Wine
> 1.1.33 is, I don't know if it's worth still doing that, or if we should go
> straight to 1.2 (or even 1.2.1).

The only reason I would think 1.1.34 would be useful would be as a
test to get updating/packaging/etc. working. Other than that, not
worth it, let's skip straight to 1.2.1 for stable and 1.3.X for
unstable.

>> I also noticed that wine --version reports wine-1.1.33-359-g680678e,
>> e.g., it's reporting the git sha1, rather than wine-1.1.33 or
>> wine-1.1.33-debian1 or something. The package is named correctly, just
>> wine is screwing it up...Has this always been a problem, or did I do
>> something wrong?
>
> I have no idea, I haven't checked this at all... My wine package reports
> wine-1.2.

I have a feeling it's git-buildpackage causing it. The version
information is derived from a script, and since we've applied a few
patches on top of plain wine, the sha1sum changes. If you're building
from a tarball, it shouldn't happen.

It's probably easy to fix, I'll take a look when I get a chance. Not a
big deal, compared to the other stuff.

-- 
-Austin