MOTU application for Scott Ritchie (third)

[Scott Ritchie]

Emmet Hikory wrote:
> Scott Ritchie wrote:
>> Having been through the sponsorship process now for two release cycles,
>> as well as maintaining several packages on my own that won't make it
>> into Hardy, I feel the time is right for me to apply to MOTU again.
> <...>
>> Having official MOTU status isn't something I necessarily need - my work
>> has gotten in for the past few years without it.  However, as I
>> understand it \sh has been rather looking forward to when I can take
>> control over my own uploads for the Wine package so he can get to work
>> on other things.  So, I humbly submit my (third) MOTU application.  If
>> there's any more information needed I'll be happy to provide it.
> 
> Scott Kitterman wrote:
>>  FWIW, I stand by my previous endorsements.  Additionally, I've noticed
>>  Scott more active on IRC on non-WINE topics.
> 
>     While I've also seen Scott more active on IRC regarding both other
> packages surrounding WINE, and non-WINE topics, this has yet to
> translate to non-WINE uploads, or demonstration of packaging skills
> outside of WINE.  I must say I am happy to see WINE appearing in the
> sponsors queue occasionally (if typically only for very brief periods
> of time and often grabbed by the same highly interested sponsors).
> 
>     Reading the results of the last application, I suspect that the
> same issues raised there (small number of uploaded packages, small
> number of sponsors) would be raised again.
> 
> Scott,
>     While it is certainly a higher burden than is asked for many
> applicants, due to the small number of packages affected, could you
> please describe some of the more difficult packaging problems you've
> encountered with your packages, and the methods you used to resolve
> them?
> 

A little over a year ago, the Wine packages would not build on amd64.
Wine is a critical app for many people, and I often found people
advising others to use i386 entirely because of this deficiency in Wine.
 Wine has to be built in 32 bit mode, exactly because people use it to
run 32 bit Windows applications - this presents a problem on amd64
Ubuntu, where we lack almost every 32 bit library by default.

The solution was to work around the problem by using the ia32-libs
package.  It wasn't, however, this simple - Wine's configure script
requires .so symlinks to the libs it eventually links against, however
we don't provide them.  The ultimate solution was an elegant hack:
manually creating .so symlinks in a temporary folder to every needed lib
at package build time.  This same strategy would later find its way into
the zsnes package with its port to amd64 (which, at the moment, is
unfortunately being blocked by a listing in the Packages-Arch-Specific
file).

While my work on Wine did lead to some improvements to ia32-libs
(including support for missing packages), it's also lead me to a
discussion with pitti about how to best eliminate it: it's a huge
package that has to be redone whenever a single component is updated,
packages have to be freshened by hand, and there's not even a mechanism
for ensuring security updates get pushed.

For Gutsy, Wine's support for applications using copy protection ran
into some unexpected breakages.  Ubuntu users were unable to run
programs that seemed to be working in Wine's application database.  The
reason turned out to be changes in Gutsy's default GCC - Wine uses some
pretty esoteric means of mapping memory to make copy protection work
just right, and later GCCs introduced optimization that effectively
broke Wine on these applications.  Hand-coding the package to build with
GCC 3.4 solved those problems.  With 4.2 in Hardy, things may be better
now, though we might have to revert to 3.4 before release - we're gonna
use the beta test period to see if anyone can find any breakages.

Another problem that used to plague the Wine packages was a lack of
obvious usability.  New Wine users didn't know what to expect - I often
had to field questions from new users asking something like "how do I
run Wine?"  Most of these users apparently had heard that Wine was an
emulator and expected something like, say, zsnes.  Aside from changing
the package description slightly and completely revamping the upstream
FAQ, most of the questions were fixed by adding some default desktop
entries to the wine package.  Using community icons, I added
applications menu entries for Winecfg, Wine's uninstaller program (that
most users didn't know existed previously), and a link to browse their
(hidden) virtual C:\ drive.

While this greatly improved usability, a few users were still wondering
how to "run Wine," not understanding that instead they simply run
applications with it.  So I added a simple link to Wine's built-in
notepad program, and placed it right inside Wine's application menu
(Applications->Programs->Accessories->Notepad).  This made it much more
obvious to users what would happen - they would install applications,
which would then add themselves alongside notepad just as Windows
programs add start menu entries.  Users still have trouble with Wine
usability, and I've been working on making it even easier for Hardy + 1
by coordinating upstream, however the package is vastly improved over
where it started.

Recently, the Hardy packages had been apparently building fine, however
they were instantly segfaulting on startup.  Despite only being in Hardy
Alpha 5, we nevertheless got about 50 people posting in over 10
duplicate bug reports of the problem.  The problem was ultimately solved
by \sh after being traced to changes in default environment variables at
build time, however investigating the problem was very educational.


>     Also, as you seem to be developing greater interest and activity
> in other efforts, are there any plans you have for other parts of the
> distribution if you were to become MOTU?
> 

Working on Wine and usability has lead me to many seemingly unrelated
areas.  For instance, because I run one of the most popular third party
repositories I've learned first hand about the issues users run into
with them, prompting me to lead a discussion about how to handle Third
Party Apt repositories last UDS.  When implemented, this spec will
likely mirror OpenSuSE's OneClickInstall file format (and, indeed, be
compatible), and I look forward to making that happen well.

Similarly, working on Wine also prompted me to learn, of all things,
python.  There has been some interest in making a winelib-aware scons
capable of easily making any Windows application cross-platform. I
envision a day where I can take some random Visual Studio project, run
it through a python script, and then end up with an scons-powered build
system that can build and run on Ubuntu using Wine.  Amazingly, when
built this way, applications don't even need to be restricted to the
arches that Windows supports - there's no reason you couldn't run a
Winelib-recompiled Windows program on, say, sparc.

This leads me to another goal: creating packages for free Windows
software that depend on Wine.  There are a substantial number of useful
programs out there lacking good Linux equivalents.  eMule is my favorite
example of this - there've been quite a few attempts at ports (lMule,
aMule), however they're never quite as feature complete or slick as the
official eMule client.  This happens with a lot of software - porting
without Wine is a large amount of work, and when it happens at all there
is often far less developer time available for Linux.  If I can make a
good Wine-based port of a program like eMule, from compilation to
packaging, and then document how I did it, then our potential software
base grows dramatically.

Properly destroying ia32-libs by creating 32 bit versions of needed
packages is another project I might undertake as a MOTU.  I mentioned a
bit about this above, however the specifics of it and the transition
plan will need to be covered next UDS.

Unrelated to Wine, I've also become very interested in improving our
games packages.  Although they were built too late to be included in
Hardy, I've worked hard to properly package the game Spring for Ubuntu.
 It's currently sitting in a PPA on launchpad, however it's being used
quite heavily by the Spring community.  Aside from Spring, I look
forward to working on other games and little unpackaged applications I
happen to use every now and again.


If you have any more questions, please feel free to ask.

Thanks,
Scott Ritchie