Bad CPU autoscaling is making games unplayable for a lot of users
Over the past couple years I've been able to try out Wine games on many different environments -- laptops, desktops, even cloud servers. On many occasions, I've discovered that a game appears to run functionally but slowly, however upon further investigation I find that forcing the CPU to run at 100% performance mode can make the game playable. There are a few tools to do this (eg cpufreq-indicator for desktop users), however the long and short of it is that, for many users, I suspect they just assume Wine is slow and give up on that particular game. 1) Since Wine is truly CPU-bound here, why isn't it provoking the autoscaling to actually speed up the processor? I've seen this happen on systems running with AC power and 100% battery life. 2) Is this a kernel issue? A distribution power management configuration issue? Or is there something we can do in Wine itself to be less courteous? Mostly I've seen this on Ubuntu, however I'm sure it's affecting other distributions that have any sort of power managment whatsoever as it can be quite tricky to get this right. Thanks, Scott Ritchie
Re: [PATCH] mscms: Use lcms2, when available
On 05/09/2013 01:37 PM, Hans Leidekker wrote: On Thu, 2013-05-09 at 18:56 +0200, wine@web.de wrote: Hi Hans. lcms2 was released on 8. May 2010 lcms v1 is on the way to be phased out in the newest distribution versions. Are there any distributions that have released without v1? I don't know, but Ubuntu has a bug for replacing lcms v1. There is no reason, that Wine is the last app, which depends on lcms v1. For most apps it will be a matter of adding a configure check for lcms2 and then recompiling. This is not the case for Wine as you have pointed out. At this point there's probably still a substantial number of users on distributions that don't include lcms2, and trying to support both doesn't make the source any prettier. So it doesn't seem unreasonable to wait a little longer. On the Ubuntu side, all supported versions have liblcms2. As far as source prettiness goes, it will be much easier to manage the transition as a distribution if we can know that Wine is ready rather than waiting on others to act (who in turn may be doing the same thing). Thanks, Scott
Re: Wine History
On 04/20/2013 05:50 PM, André Hentschel wrote: Hi, meanwhile everyone should know that Wine turns 20 this year. AJ said in this years Keynote we'll need to find a way to celebrate this in June. So i did some research on this and found Wine History mails by Dan Kegel from 2002 and much earlier Bob Amstadt talking about late May or early June 1993. The date listed on Wikipedia is July the 4th, but i was still curious about that late May. I think i finally found this late May (30th) discussion and want to share it: https://groups.google.com/d/msg/comp.os.linux/7TFhxP6IUVQ/gVHAeP_ZBVUJ It's of course hard to tell when a project was really born, but as far as i understand, this discussion inspired Bob to write an initial loader. I was just 5 at this time, so maybe someone can tell some more about it? :) Reading that thread, it seems that WABI was an important Wine before Wine -- albeit proprietary and made for SunOS (and bundling a CPU emulator!) Perhaps we should mention it in our history page.
Re: Call for papers - FOSDEM 2013
Will FOSDEM manage this for us or do we need to send our own filmy person? I nominate Jeremy to investigate, we really should have this filmed. On 11/5/12 3:08 AM, Julian Rüger wrote: It would be really cool if someone could manage to record some talks and upload them to eg. youtube, for those who can't attend. I would be especially interested in Stefan's proposed talk. Thanks everyone and have a nice FOSDEM! Best regards, Julian Am Freitag, den 02.11.2012, 14:26 +0100 schrieb Stefan Dösinger: Am 2012-11-01 19:59, schrieb Jeremy White: So I would like to formally 'call for papers' for FOSDEM. Please email suggested topics to winec...@winehq.org, where I'll collate them and piece them into a schedule. Will this be talk-only or do you also plan written conference proceedings? I suspect it'll be talk-only. I propose a talk about the status of 3D rendering support for games on Linux. I don't intend to make this highly Wine-specific, and instead include the state of Mesa, fglrx, nvidia and OSX graphics drivers.
Does Wine benefit from libtiff5 over libtiff4?
I'm trying to manage building for 3 different Ubuntu releases now for our 1.5 releases, and the main delta between them is libtiff 12.04: libtiff4 available 12.10: libtiff4 and libtiff 5 available 13.04: libtiff4 and libtiff 5 available It's much simpler if I can build on 12.04 and copy the binary packages, however this means I can't use libtiff5 if I do so. Is there any benefit in doing a separate build just for this? *note that in 12.10/13.04 official archive we build seperately and just use libtiff5. Thanks, Scott Ritchie
Re: We're in at FOSDEM!
On 11/12/12 11:59 AM, Jeremy White wrote: We should stay in the same hotel if possible to ease gathering. Did someone already choose one? Could You make a special arrangement again (like in Paris, IIRC)? No, we haven't yet picked a hotel. I was poking around a bit; looks like it's not obvious. I see that other projects have varying strategies for handling this. Anyone feeling like a travel planner and want to volunteer for that job? Or anyone know Brussels and/or FOSDEM such that they can suggest good strategies? Cheers, Jeremy We should make a decision about Friday/Sunday (or both) soonish, as it will affect how we book our flights.
How to tell Mac from Linux wine within a Wine app? (steam hardware survey)
Is there an easy way for the steam hardware survey to tell whether it's running under Mac or Linux Wine? I remember discussing this issue with an engineer from Valve after asking they make the % of Wine users public again.
Re: How to tell Mac from Linux wine within a Wine app? (steam hardware survey)
On 11/10/12 11:20 AM, Max TenEyck Woodbury wrote: On 11/10/2012 02:03 PM, Scott Ritchie wrote: Is there an easy way for the steam hardware survey to tell whether it's running under Mac or Linux Wine? I remember discussing this issue with an engineer from Valve after asking they make the % of Wine users public again. Why do you care? The best way is probably to try something that works on a Mac, and if it comes back with 'not implemented', try a workaround that works with Wine. It would not be a good idea to infer that because one thing is broken under wine, that some other work around is also needed. Each capability should be checked separately. Things can change fairly rapidly in Wine. The purpose isn't to work around wine bugs by detecting wine, it's to find out how many Wine/Mac and Wine/Linux users there are so they can assess how that compares to the native clients.
The EFF is asking for our help explaining why APIs should not be copyrightable
https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case There are court cases pending that are very, very relevant to what we do here. It would help the EFF very much if a few engineers could send them a short email statement explaining how Wine's reimplementation of the API is good for interoperability and competition. Thanks, Scott Ritchie
What parts of gettext does Wine need at runtime?
Is libgettextpo0 (in 32 and 64 bit) sufficient? Or do we need the sort of utilities in the gettext-base package? I'm trying to fix https://bugs.launchpad.net/ubuntu/precise/+source/gettext/+bug/954029 which was largely caused by my overcautiousness here.
Re: Overriding the check for ownership of a prefix
On 9/19/12 5:23 PM, Scott Ritchie wrote: So, I believe I have a legitimate use case for ignoring this, and want to know what sort of patch would go forward. Imagine a distro package containing a Windows game in the form of a read-only copy of an installed prefix (into, say, /opt). When the user launches the app (via desktop file) this in turn launches a script that does the following: 1) Makes a temporary folder 2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the read-only packaged prefix in /opt, mounted in the temporary folder 3) Runs the app with WINEPREFIX= the temp folder 4) When the app is finished, unmounts the temp folder This all works quite fine: new (or modified) files within the prefix get stored in ~/.appname, to be restored the next time the user runs the app. Distinct users can run the app simultaneously, as they each have their own prefix. Excess file-copying is avoided, as only the user-modified files need to be stored in the home folders. There is one major snag, however: unionfs displays the owner as root until the user has modified/copied it. This means Wine refuses to launch as the user with the root-owned prefix. Simply commenting out this part of the code makes Wine work fine, however I'd like to be able to have a proper solution. I have found a better solution: you can use standard FUSE options to mask the true owner such that it is always presented as the mounting user, even if the file is untouched.
Re: Overriding the check for ownership of a prefix
On 9/24/12 2:48 AM, joerg-cyril.hoe...@t-systems.com wrote: Scott, I don't think you need to override this check, esp. given that there's a good reason for it being there: The good reason doesn't apply in this use case. Overriding it fixes every problem I'm facing without having to do anything complicated or manual. Note that there is a problem with this setup if the app modifies the registry and we then need to update the prefix-default registry I've excellent experience with symbolic links. In fact, none of the apps (games) I use are installed directly within any .wine prefix. Drive_c/Program Files/Games is a symbolic link to a large partition. Your apps don't need to have conflicting registry settings then. I can't assume I'll always be so lucky. Imagine a distro package containing a Windows game in the form of a read-only copy of an installed prefix (into, say, /opt). So I recommend the following setup: - Have the game's main directory be something like /opt/games/XYZ in UNIX, but tell it to install to C:\games/XYZ - During installation, write down all registry keys that the app creates and every file that it stores outside of its local directory. Beware: the name of the directory C:\Program.. depends upon every user's locale at .wine creation time! Use C:\Games\ instead to avoid that pitfall. For every user: - After .wine is created normally, add a symlink from Drive_c/Games to /opt/games - Add registry keys or dlls needed by the app. wineprefixcreate ln -s /opt/games/XYZ $HOME/.wine/drive_c/games cp -p whatever.dll $HOME/.wine/drive_c/windows/system32/ wine regedit xyz.reg Trivial, isn't it? We can't assume apps will install cleanly, or only need the files in their install directories; copying to windows system folder does happen, and then it becomes a real mess. Typically, you don't need to recreate the content of user-local APPDATA directories. The app will create them upon each run, since they ought to run with different users on one machine. Caveat: Although my .wine and games directories are distinct, I've no experience with write-protecting the games partition. Obviously, this only has a chance to work with modern apps, written after MS started recommending separating the app's dir from its per-local configuration files to be since stored in ~/LOCALAPPDATA or the like. Thus w9x/w2k-era games are ruled out. Still, I don't know where those apps attempt to store e.g. crash logs. I've seen apps write high-scores or savegames to their central directory when w2k was set in winecfg, and use HKCU/LOCALAPPDATA (what's the exact name?) when running in xp mode. I've made excellent experience with plenty of apps sharing a single .wine-games prefix with such a setup. I.e. you don't need one prefix per app. Like on a real box, the apps ought to be able to coexist. Perhaps. But separate prefixes give us so many advantages here, at the mere cost of some disk space. Drawback: when I was initially attracted to Wine 5 years ago, every .wine was a tiny 3-4MB. Nowadays it's more than 10 times that size, and I'm not happy with that. Using a single onion-union-fs to share drive_c/xyz may be interesting -- for as long as one single version of Wine is in use. Regards, Jörg Höhle Thank you though, you do propose one alternative.
Re: Overriding the check for ownership of a prefix
On 9/20/12 3:07 AM, Francois Gouget wrote: On Wed, 19 Sep 2012, Scott Ritchie wrote: [...] There is one major snag, however: unionfs displays the owner as root until the user has modified/copied it. This means Wine refuses to launch as the user with the root-owned prefix. Wine checks the ownership of the $WINEPREFIX directory right? So wouldn't touching a file in $WINEPREFIX before starting Wine work? system.reg would be a good candidate. Alternatively, create/delete some other file. Yes, unfortunately unionfs displays a sort of mixed permission structure: files are owned by the user once they are modified, but the hosting directory name itself can't be modified in this way, which is exactly what Wine checks.
Overriding the check for ownership of a prefix
So, I believe I have a legitimate use case for ignoring this, and want to know what sort of patch would go forward. Imagine a distro package containing a Windows game in the form of a read-only copy of an installed prefix (into, say, /opt). When the user launches the app (via desktop file) this in turn launches a script that does the following: 1) Makes a temporary folder 2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the read-only packaged prefix in /opt, mounted in the temporary folder 3) Runs the app with WINEPREFIX= the temp folder 4) When the app is finished, unmounts the temp folder This all works quite fine: new (or modified) files within the prefix get stored in ~/.appname, to be restored the next time the user runs the app. Distinct users can run the app simultaneously, as they each have their own prefix. Excess file-copying is avoided, as only the user-modified files need to be stored in the home folders. There is one major snag, however: unionfs displays the owner as root until the user has modified/copied it. This means Wine refuses to launch as the user with the root-owned prefix. Simply commenting out this part of the code makes Wine work fine, however I'd like to be able to have a proper solution. Would something like a command-line switch or environment variable be acceptable here? Thanks, Scott Ritchie * Note that there is a problem with this setup if the app modifies the registry and we then need to update the prefix-default registry, but that's a different feature request
Spam applications for testbot accounts
Never underestimate the overeagerness of bots, I suppose... We're getting a lot of spam applications for testbot accounts now, maybe 2-3 per day. Some are easy to discard because they put stuff like penis pills into the info field, but others look like just names. Suggestions are welcome. In the meantime it would be nice if anyone requesting a legit account put some sort of non-spammy text in there like Hey I'm a human I read wine-devel
Re: Have there been any problems with Wine on GCC 4.7?
On 8/21/12 12:17 PM, Austin English wrote: On Mon, Aug 20, 2012 at 11:55 PM, Eric Pouech eric.pou...@orange.fr wrote: http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d -- -Austin the trouble with this patch is that it enables debug info whatever the default configuration is... A+ -- Eric Pouech -g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. Correct, the symbols get split out (in Ubuntu Packaging this is handled mostly automatically after just giving the name of the debug package) -Scott Ritchie
Re: Have there been any problems with Wine on GCC 4.7?
On 8/13/12 12:55 PM, Eric Pouech wrote: diff --git a/configure.ac b/configure.ac index 4bd43d1..c80fd8a 100644 --- a/configure.ac +++ b/configure.ac @@ -1746,6 +1746,8 @@ then WINE_TRY_CFLAGS([-Wtype-limits]) WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) WINE_TRY_CFLAGS([-Wwrite-strings]) + WINE_TRY_CFLAGS([-gdwarf-2]) + WINE_TRY_CFLAGS([-gstrict-dwarf]) dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections case $host_cpu in would be simpler, unless I'm missing something. would work too (even if this would be preferable) + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf]) Or I could not patch Wine itself and instead patch it's build instructions in the package rules file. But if Wine indeed doesn't work with GCC's new default settings then it should probably be a Wine page (for every distro)
Re: Have there been any problems with Wine on GCC 4.7?
On 08/12/2012 01:08 AM, Eric Pouech wrote: Le 24/07/2012 04:06, Scott Ritchie a écrit : Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? Thanks, Scott Ritchie afaik, gcc 4.7 enables by default dwarf4 as its default debug format, whilst wine (dbghelp) only supports dwarf2 it generates a lot of conbursome backtraces in winegdb I've started to add dwarf4 support to wine, but don't hold your breath (it's going to be hard and tedious afaict and will require quite a few changes to dbghelp for correctness) (and I have little time right now g) BTW : fedora 17 ships with gcc 4.7 A+ In the meantime, I suppose I could enable the -gdwarf-2 compiler option. Thanks, Scott Ritchie
Wiki seems to be down.
Thank you :)
Have there been any problems with Wine on GCC 4.7?
Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? Thanks, Scott Ritchie
Re: Have there been any problems with Wine on GCC 4.7?
On 07/23/2012 07:44 PM, Austin English wrote: On Mon, Jul 23, 2012 at 7:06 PM, Scott Ritchie sc...@open-vote.org wrote: Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? Thanks, Scott Ritchie My understanding was that the problems introduced in 4.6 are still in 4.7. Would you mind pointing me to the GCC bugs / test cases we have for this? I seem to remember them being a bit impractical (ie, run this 2 gb proprietary app and watch it break), but I think I can help refer the right people. Thanks, Scott Ritchie
Re: Ubuntu 12.04 (version#2, drop previous mail)
On 5/1/12 2:32 AM, Eric Pouech wrote:
This is the downside people in this thread are complaining about:
compiling 32-bit programs on a 64-bit Ubuntu install is now slightly
more difficult. However, Wine is currently the _only_ piece of
software I've encountered that needs to be built for both arches on
the same machine in order to be usable. We are beautiful special
snowflakes here: Wine developers who aren't using the build daemons is
about the extent of the current use case.
snip
I'm beginning to have memories of what happened when we removed gcc
from the default install. Setting up a 32-bit chroot for building Wine
should not be complicated -- I'll present a script to make it even
easier soon. You can build in a single command and even use things
like ccache and the like to speed it up.
to summarize:
ubuntu doesn't do anything to support developers
as it implies using ubuntu build daemons, not developers' machine (and
all the relevant environment)
as it implies to use chroot even on a multi lib arch = multi arch is
then for users, not developers
bye bye ubuntu then
If this is a blocker for you then I can't blame you then.
For reference the only successful way to build Wine I'm aware of is
http://wiki.winehq.org/Wine64ForPackagers under the Alternatives
section (ie, manually configuring and building 32 and 64 separately and
copying files from one into the other.) You may be able to do that
without a chroot (or something similar like pbuilder),
for the sake of record (I won't even dare to send it to wine-patches) a
workaround ubuntu recvmsg breakage in order to get ptrace API to be
usable on 12.04
diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c
index 8a01d22..6c8e759 100644
--- a/dlls/ntdll/server.c
+++ b/dlls/ntdll/server.c
@@ -1016,6 +1016,37 @@ void server_init_process(void)
send_server_task_port();
#endif
#if defined(__linux__) defined(HAVE_PRCTL)
+ /* work around Ubuntu's recvmsg breakage */
+ if (!server_pid)
+ {
+ int zfd;
+ struct flock fl;
+ char tmp[4096];
+ strcpy(tmp, wine_get_server_dir());
+ strcat(tmp, /);
+ strcat(tmp, LOCKNAME);
+
+ if ((zfd = open( tmp, O_RDONLY )) == -1)
+ fatal_error( no lock present %s.\n, tmp );
+
+ fl.l_type = F_WRLCK;
+ fl.l_whence = SEEK_SET;
+ fl.l_start = 0;
+ fl.l_len = 1;
+ if (fcntl( zfd, F_GETLK, fl ) != -1)
+ {
+ if (fl.l_type == F_WRLCK)
+ {
+ /* the file is locked */
+ fprintf(stderr, getting server_pid from lock %d\n, fl.l_pid);
+ server_pid = fl.l_pid;
+ }
+ fatal_error( cannot get pid from lock (lock isn't locked)\n);
+ }
+ else
+ fatal_error( cannot get pid from lock\n);
+ close(zfd);
+ }
/* work around Ubuntu's ptrace breakage */
if (server_pid != -1) prctl( 0x59616d61 /* PR_SET_PTRACER */, server_pid );
#endif
I showed this to the developer who originally wrote the kernel ptrace
stuff, and indeed this seems like an upstream kernel bug, albeit in
recvmsg rather than ptrace (also note that the ptrace stuff is now in
the mainline kernel as well, not just Ubuntu, so you may have found a
problem that was just exposed in Ubuntu first).
Anyway, I'll follow up on it. In the meantime I'm pushing your patch in
a stable release update for Wine (once I test another thing), so thank
you very much for it.
Thanks,
Scott Ritchie
Re: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 1:37 AM, Eric Pouech wrote: This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least Some context would help here: In previous Ubuntus we ran into quite a few bugs (eg Wine's mpeg123 issues) that occurred because we used a 64-bit header file with a 32-bit library and .so symlink. This in turn was because the package manager did not have a concept of foreign-architectures -- 32-bit support on Ubuntu64 was done by installing a giant omni-package called ia32-libs that contained every library that might ever be useful (plus some .so links). Things are _much_ better in 12.04. Wine can actually be built and installed biarch as a user package! Ubuntu users are, for the first time, actually using 64-bit Wine when possible because the package manager understands multiarch and, more importantly, because the underlying libraries are coinstallable with themselves. This was not done for the -dev packages yet due to lack of time -- getting the actual libraries in users hands so programs like Wine can work was much more important. So some foo-dev:i386 will install, but will erase foo-dev:amd64. This is the downside people in this thread are complaining about: compiling 32-bit programs on a 64-bit Ubuntu install is now slightly more difficult. However, Wine is currently the _only_ piece of software I've encountered that needs to be built for both arches on the same machine in order to be usable. We are beautiful special snowflakes here: Wine developers who aren't using the build daemons is about the extent of the current use case. Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ I'm beginning to have memories of what happened when we removed gcc from the default install. Setting up a 32-bit chroot for building Wine should not be complicated -- I'll present a script to make it even easier soon. You can build in a single command and even use things like ccache and the like to speed it up. Thanks, Scott Ritchie
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 2:17 AM, GOUJON Alexandre wrote: On 04/29/2012 10:44 PM, Eric Pouech wrote: for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile That's funny because I just tried yesterday and filed [1] to see what developers think. They are aware of the issue but will need some time to fix it. What I discovered is that installing gcc:i386 on amd64 doesn't mean what we think. It replaces the (amd64) gcc and wants to remove gcc and build-esential (and others). What we want is gcc-multilib which provides libc6-dev-i386. The other way also exists with libc6-dev-amd64:i386 (compiling programs targeting amd64 from a i386 computer) For the other issues, I guess we'll have to file as many bug as packages which are not multiarch-able. (I don't know how to say it, hope you get the idea) Yes, this would be prudent. Tag them multiarch too. It's the next phase of the multiarch transition (there are a few lingering packages that aren't properly multiarch as well. It's a good chunk of work, as we have to go package by package and identify if they: 1) Have architecture-specific strings in the -dev stuff 2) Move them into arch-specific folders when appropriate 3) Move files that aren't arch-specific into -common packages that are arch:all 4) Tag the resulting package multiarch: same 5) Send changes back to Debian (which is still in the multiarch bronze age) Thanks, Scott Ritchie
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
On 4/30/12 6:24 AM, Julius Schwartzenberg wrote: Eric Pouech wrote: Le 29/04/2012 22:44, Eric Pouech a écrit : for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation I forgot to mention that ubuntu devels did a crappy job in 12.04 I'm really starting to get angry at their inability to take care of upward compat in what they do Maybe looking at 'sudo apt-get build-dep wine' and the Wine packaging scripts will also reveal what's needed to build 32-bit Wine on Ubuntu 12.04 64-bit. In general the 12.04 release still has loads of bugs however. It seems the developers couldn't manage to look over all the reported bugs anymore before the release, but decided to release anyhow. They probably only focused on the crash bugs, because there are not many crashes, but many things do not work yet as they should. I expect 12.04.1 will contain a very significant amount of fixes. It's sort of a consequence of time-based releases, unfortunately. We were very conservative about new versions of stuff that got into 12.04 to try and minimize new bugs, but stuff invariably comes up. Thanks, Scott Ritchie
Re: Mono packaging status
On 4/23/12 1:45 AM, Jacek Caban wrote: On 4/20/12 11:29 PM, Scott Ritchie wrote: On 4/19/12 1:54 AM, Jacek Caban wrote: Hi Vincent, On 04/19/12 00:12, Vincent Povirk wrote: If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around. The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through. Cheers, Jacek Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal release via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past. I'm not sure what limited space you mean. We already have Wine Gecko on SourceForge and a redirecting script on source.winehq.org, which is used for automated downloads. AFAIK this way we don't have any limitations and, as far as Wine packages are concerned, we don't depend on any specific external mirror provider. Perhaps I am misremembering bandwidth limitations as space ones, but I do recall that hosting the Ubuntu packages there simply did not work once we had more than a few thousand users long ago. Depending on how frequent a download mono is, we may run into the same issue (with a similar solution: most Ubuntu users don't ever hit the sourceforge gecko download because they get gecko from an automatically installed package that comes with the Wine package) Thanks, Scott Ritchie
Re: Mono packaging status
On 4/19/12 1:54 AM, Jacek Caban wrote: Hi Vincent, On 04/19/12 00:12, Vincent Povirk wrote: If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around. The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through. Cheers, Jacek Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal release via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past. Thanks, Scott Ritchie
Re: Regression testing
On 4/12/12 1:23 AM, Daniel Jeliński wrote: Hello all, I am trying to get Microsoft SQL Server Management Studio to work flawlessly under Wine. For the most part I create and triage related bug reports, but recently I also started tinkering with code, specifically with comctl library, which I am most familiar with. Back on subject. I thought I found a regression - on Wine 1.4 package downloaded from launchpad the New query button works fine, while on my compiled Wine it produces an error. So I did: git reset --hard wine-1.4 make and, surprisingly, I still had the problem with the compiled version. However after some combination of deleting leftover files, running make clean, make depend and make the button started working, so I started bisecting, hoping for the best. At some point I started getting bad versions, and every subsequent compile was bad - even after I ended bisecting and returned to wine-1.4, the button still did not work (and it still works under packaged Wine - I use the same install for all tests). This time make clean make depend make did not help. Packaged Wine might be different for a few reasons: 1) It is a hybrid 32+64 build, which you can't get in one step on Ubuntu 12.04 anymore 2) It uses GCC-4.5 (12.04 default is 4.6) 3) It has one small patch for fonts (shouldn't matter in your case) 4) It's built in a clean environment on the build daemon 5) It's installed and run out of tree. Thanks, Scott Ritchie
Building the 1.6 Release Notes as things are written.
So, congrats everyone, 1.4 is out and I'm very happy about it :) I wanted to thank Alexandre for his release announcement, it was very through and informative. It also looked like a lot of work. This made me wonder if we could instead build up the announcement gradually with some sort of process. For instance, if every significant feature added to a development release were put onto a wiki page, then at any point in time we could point someone there to answer a general what does 1.5 have over 1.4? question. Come 1.6 release time, we could just copy and edit the page as the official announcement. Thoughts? -Scott Ritchie
Re: Best way to overlay a filesystem for a Wine app?
On 01/30/2012 01:58 AM, Francois Gouget wrote: On Fri, 27 Jan 2012, Scott Ritchie wrote: [...] To me, this sounds an awful lot like an overlay file system. Would unionfs-fuse be the correct solution here? The .desktop file that sets the Wine prefix and also launches the app could mount the FUSE filesystem, and the user-space Wine prefix's files could take priority over those in /opt. Stuff like user-modding and update/repair systems could work properly in that context as well. The main issue with copy-on-write overlay filesystems is that they cannot deal with registry files for two reasons: * First, once a file has been written to and thus copied to the user's wineprefix, it will never be updated when you upgrade the application's package. This means after an upgrade the user's system.reg and user.reg files (the latter containing the dll overrides) will be unchanged which may cause the application to be broken. Well, provided the app doesn't change it's registry entries, it should be ok then. But couldn't we extend Wine a bit in the other case? For instance, maybe app's changes could be merged in via Wine's normal method of updating the registry on (Wine) upgrade (/usr/share/wine.inf)? It would require giving Wine some sort of switch to point to a supplemental file. * The second issue is that the registry really contains both application data and user data. The former should be upgraded while the latter should be preserved. So neither a copying the new registry files nor preserving the old registry files policies are appropriate (and these policies are the only two available to overlay filesystems). If the user never customizes the app-specific prefix with winecfg or similar, then copying the new registry should work yes? Besides that there are other issues, most of which Dan already mentioned: * As far as I know most overlay filesystems don't deal well with changes in the underlying filesystem. This pretty much breaks the upgrade scenario. Do you mean upgrading while the filesystem is mounted? Or just any change at all? * They are not available on all Linux distributions (not to talk about Mac OS X or FreeBSD). But I guess this is fine for a latest-Ubuntu-only approach (like for menus and the trash!). Yeah the idea is to do this moving forward rather than create a universal linux package. Another issue is applications that require a license key to be entered during installation. This causes trouble for both the overlay and symlink approaches since both have the packager install the application and then ship the installed image... along with its single license key. So for these applications a way to enter the license key on first run has to be found. Agreed, keys will be a problem. Thanks, Scott Ritchie
Re: Best way to overlay a filesystem for a Wine app?
On 01/29/2012 02:38 PM, Dan Kegel wrote: Hi Scott, I agree with what Vrit said. Here's what I recall learning from helping package Picasa: - don't package the installer Right, run the installer and use the contents of the result as the packaged files. - rely on the system's update manager to pull updated versions of the package from the repository This may not be a fast-enough option for some apps, such as online games that need to keep everyone in version sync. Even in an ideal case where the company was 100% behind the Ubuntu package and kept it in sync with their release process, there is still no current way for the Windows app to tell Apt to update its package. - install everything read-only into /opt/companyname/appname - start the app using a shell script that creates a wineprefix on 1st run - The wineprefix should have real directories (so the app can create files in Program Files, ugh), should symlink to all the readonly files in /opt, and have real copies of any files that can't be read-only As Vrit said, the script that creates the wineprefix is very app-specific, but once you write one, it's probably easy to write the next one. Perhaps I'm speaking from inexperience with either, but wouldn't a unionfs-fuse overlay be simpler and cleaner than this since you wouldn't have to worry about the app-specific stuff at all? - If you are running your own repo, you should put exactly one app per repo. Otherwise you run into trouble because Canonical would want to review all the apps in the repo every time you update any one of them. This is already how apps work in the App Store - commercial apps get their own repos, if they require payment then it's a private launchpad PPA, and the user gets a unique access key when they buy it. So no overlay filesystem needed, symlinks should usually suffice. (Picasa also went further and bundled a snapshot of wine, too, and modified the app slightly to display unix paths, which required adding one little extension to wine. I'm sure the wine patch is around if someone wants it. And since it was in a non-ubuntu repo, it had to do a strange song and dance to avoid autoupdates being disabled when the user upgraded to a new version of ubuntu. This was considered safe because picasa was fairly well self-contained and maintained, and was unlikely to break on system updates.) This patch would be interesting if you could dig it up. I don't know if Alexandre would accept it, but ideally it would be part of Wine and turned on via an environment variable or command line switch. In case you want to look at picasa's scripts, the download page seems to be gone, but the repo seems to still be there: http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i386.deb http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd64.deb 4ecf30186ce76430a7791cee2608f47e07b015e6 picasa_3.0-current_amd64.deb fe8e83b29a10b5d663e87861d85512faea036c06 picasa_3.0-current_i386.deb Still installs and runs ok on 11.10. Thanks! Thanks, Scott Ritchie
Best way to overlay a filesystem for a Wine app?
Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store. Ubuntu requires these commercial packages: 1) Install into a unique namespace in /opt (icons/.desktop excepted) 2) Store their user configuration in ~/.packagename or ~/.config/packagename I have already packaged a super-simple Wine application this way. This was a single binary file that could be run from anywhere - all I had to do was copy it into its own /opt folder and make a .desktop file that declared a unique WINEPREFIX for it. More complicated Windows applications, however, won't be doable with this basic approach. Specifically, Windows applications might: 1) Be distributed as installer files 2) Have self-updating mechanisms 3) Expect their own folder to be user-writable One ugly not-quite-solution would be to just have the package put the installer in opt, provide a link to it, and expect the user to install like he would a downloaded application (and then use a different .desktop file to actually run the program). Slightly better is to just copy an entire /opt prefix template into user space on first run, and then let it go on its own way after that. An app which didn't self-update, however, would then be unable to benefit from an updated version of the system package. A more complete solution would have a prefix in the user space, but files inside it would actually be those residing in /opt. A system of symlinks might work, but if a package update introduced new files those would not be available without complicated scripting to add the links. To me, this sounds an awful lot like an overlay file system. Would unionfs-fuse be the correct solution here? The .desktop file that sets the Wine prefix and also launches the app could mount the FUSE filesystem, and the user-space Wine prefix's files could take priority over those in /opt. Stuff like user-modding and update/repair systems could work properly in that context as well. Or have I missed something? Thanks, Scott Ritchie
Interesting - performance issues in Natural Selection 2 dedicated server
The game is still in beta development, but I just learned something odd - there are no Linux server binaries (yet), and a lot of admins are running the dedicated server using Wine. Wine works, but is actually performing fairly poorly here. I find this really interesting, as the dedicated server isn't graphical in any way. Would profiling here be worthy of pursuing? Are there known areas of bad performance other than graphics? Thanks, Scott Ritchie
Re: Any bad side-effects from not building with HAL if udisks is enabled?
On 01/04/2012 10:26 AM, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: Assuming udisks support exists on the system, anything wrong with this? Does the new udisks do everything HAL used to do? If udisks is present, the HAL support is not used at all. Perhaps the configure warning could be suppressed or changed in that condition? Thanks, Scott Ritchie
Any bad side-effects from not building with HAL if udisks is enabled?
Assuming udisks support exists on the system, anything wrong with this? Does the new udisks do everything HAL used to do? Thanks, Scott Ritchie
NVidia Texture Tools still useful?
I found this old bug report today, that I had forgotten about: https://bugs.launchpad.net/ubuntu/+bug/382512 Do we still have a use case for NVidia Texture Tools if I put these packages into the distro? Thanks, Scott Ritchie
Would making the Wine file dialogs know about the Nautilus bookmarks be a reasonable thing?
Assuming you're running Gnome, as I'm not sure there's a freedesktop standard for the Bookmark feature yet (and perhaps there should be). In every Gnome nautilus window, save dialog, and file open dialog there's a standard set of folders you see on the side as quick links. Some are obvious, and we duplicate them (eg Desktop), others are automatic, like gvfs links to external hard disks. Users can also add their own. Would it be appropriate to display those self-added bookmarks in Wine? I'm worried there might be something I'm missing about the implementation that would make this difficult or a bad idea. Thanks, Scott Ritchie
Re: Regression testing breakthrough
Exciting! On 10/18/2011 01:45 AM, Damjan Jovanovic wrote: I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Perhaps you could use an intermediary server and a script. The user tells the script works or doesn't and then the script fetches the binary via rsync from a special directory on the server that has the git repo there. That way the user only needs to download the binaries he runs, and even then they'll be done incrementally via rsync magic. Thanks, Scott Ritchie
Re: winecfg: Remove driver selection from Audio tab.
On 09/28/2011 05:57 AM, Vitaliy Margolen wrote: On 09/28/2011 04:18 AM, Alex Bradbury wrote: Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them. If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16. Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old stable versions. There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough. -Scott
Re: winecfg: Remove driver selection from Audio tab.
On 09/28/2011 10:10 AM, Austin English wrote: On Wed, Sep 28, 2011 at 11:55, Scott Ritchie sc...@open-vote.org wrote: On 09/28/2011 05:57 AM, Vitaliy Margolen wrote: On 09/28/2011 04:18 AM, Alex Bradbury wrote: Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them. If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16. Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old stable versions. There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough. There's no reason you (as a package manager) couldn't choose a particular development release and mark it as stable in your distribution. E.g., Fedora does this, currently has wine 1.3.21, unless you enable updates-testing, which has 1.3.29. In any case, I think this topic is best reserved for discussion at Wineconf, especially since it's not that far away ;). Yes, I already ship a Wine1.3 package in the install, and it should be the default most people find when searching for Wine. But that means users aren't getting the advantage of a real release process here. If that's too involved an effort to do frequently enough for distros to not feel obligated to ship development releases by default, then perhaps we need to discuss a different strategy. In either case, I think we can all agree that more automated continuous testing of git would be a nice thing to have. So I got my daily PPA, Dan's got buildbot, and many of us have been expanding Wine's test suite. I hope to also tie in automated winetricks and winetricks-style application tests to the daily PPA soon as well. Thanks, Scott Ritchie
Re: Proof of concept - The crashbot
On 09/16/2011 08:16 AM, Henri Verbeet wrote: On 16 September 2011 16:56, Seth Shelnutt shelnu...@gmail.com wrote: Personally I think automated application testing is the next major testing platform for wine. Test suites are the most important, but application testing can mean knowing when new software works in wine and from a user standpoint of view more interesting and applicable than what test suites are getting passed. It's something we've been interested in for some time, but it's fairly hard to make it work in a reliable way. I think it's slightly easier to do the inverse -- automate applications to make sure they don't crash in future versions. I'm going to tackle something similar on the daily Ubuntu builds with winetricks' included selftest once Launchpad starts building them again. Thanks, Scott Ritchie
Re: ubuntu ppa -- nice to have on development version too
On 09/03/2011 03:54 AM, Scott Ritchie wrote: On 09/02/2011 10:04 AM, Susan Cragin wrote: There was discussion about putting a daily wine build on the ubuntu ppa. I'd like to put in a word for having it on the development version (currently oneiric) as well as the stable version (natty). Right now wine only seems to have a natty ppa. Yes I'll do an oneiric recipe soon. Just as an update, the only reason I haven't done this yet is because launchpad itself is having problems: Apparently the build process is only given so much memory and importing Wine's git tree somehow manages to consume all of it. This is also why the daily builds have stopped being daily. You can see the bug here: https://bugs.launchpad.net/bugs/746822 Thanks, Scott Ritchie
Re: buildbot status
On 09/01/2011 10:50 AM, Henri Verbeet wrote: Looking at this from a slightly different angle, I think that if you expect people to take buildbot results seriously, you should run it on a configuration that's known to be solid, so that people can be confident any failures are actual issues with the patch, instead of e.g. fglrx or Ubuntu breaking something again. Finding out when Ubuntu breaks something is important too, and indeed one reason I started the daily Ubuntu builds and will be doing them with the development release. A testbot can't really know if it was Ubuntu breaking something or us breaking something that was only exposed on Ubuntu. We can make prior assumptions for individual machines though, such as it's usually fglrx's fault, and adjust our behavior/failure warnings accordingly. Thanks, Scott Ritchie
Re: Getting Wine's PO files on Launchpad
On 09/04/2011 03:26 PM, Francois Gouget wrote: * Launchpad would need to pull updated PO files from Wine regularly. Ideally that would be automatic and happen daily (both to account for translations happening outside Launchpad and to take changes in the resource files into account quickly). https://help.launchpad.net/Translations/YourProject/ImportingTranslations Launchpad already has a bzr branch for Wine that we should use here (via bzr-git imports) rather than messing with manual tarball uploads. https://launchpad.net/wine You can, for instance, do bzr get lp:wine (at least on an ubuntu machine) Thanks, Scott Ritchie
Re: Getting Wine's PO files on Launchpad
On 09/05/2011 04:46 AM, Henri Verbeet wrote: On 5 September 2011 10:38, Michael Stefaniuc mstef...@redhat.com wrote: Permission to relicense the existing translations with a BSD license... https://help.launchpad.net/Translations/StartingToTranslate#Licensing_your_translations The license itself is sane but it will require quite some work and time to accomplish the relicensing. While BSD is an acceptable license, I can't say I'm really a fan, or that it's something I'd like to encourage. I'm probably the only one with that opinion though, and not much of a translator. I think the technical reason for this is that launchpad has a growing intelligence about suggested translations built on its evergrowing database of translations. That requires a permissive license for its new translations, since the suggestions could be applied to different projects that might fall under different copyrights. Thanks, Scott Ritchie
Re: ubuntu ppa -- nice to have on development version too
On 09/02/2011 10:04 AM, Susan Cragin wrote: There was discussion about putting a daily wine build on the ubuntu ppa. I'd like to put in a word for having it on the development version (currently oneiric) as well as the stable version (natty). Right now wine only seems to have a natty ppa. Yes I'll do an oneiric recipe soon.
Daily builds of latest Git now available as Ubuntu packages
For an easier user testing experience, you can now install the latest git as a convenient Ubuntu package. The instructions are very similar to using the standard Ubuntu packages, however the PPA name is different. Instead of ppa:ubuntu-wine/ppa, you add ppa:ubuntu-wine/daily. From a terminal: sudo add-apt-repository ppa:ubuntu-wine/daily sudo apt-get update sudo apt-get install wine1.3 The packages are versioned like wine1.3-1.3.27+daily-20110901. Limitations: The major version number is based on the latest released version of the Ubuntu packages, so on release days you might see something like 1.3.27+daily-20110909 which would actually be equivalent 1.3.28. If I get especially behind and don't update the official packages after Monday, you might even see a 1.3.27+daily that's actually ahead of 1.3.28. In all cases wine --version should return what it normally does, however - this is just the package revision that is being wonky. Possible future: These packages are a convenient way to run some tests that may be much too slow for testbot to run against every patch, such as autohotkey-based application automation. Thanks, Scott Ritchie
Re: Daily builds of latest Git now available as Ubuntu packages
On 09/01/2011 05:21 AM, Henri Verbeet wrote: On 1 September 2011 11:50, Scott Ritchie sc...@open-vote.org wrote: The packages are versioned like wine1.3-1.3.27+daily-20110901. Limitations: The major version number is based on the latest released version of the Ubuntu packages, so on release days you might see something like 1.3.27+daily-20110909 which would actually be equivalent 1.3.28. If I get especially behind and don't update the official packages after Monday, you might even see a 1.3.27+daily that's actually ahead of 1.3.28. I don't use Ubuntu, so this doesn't really affect me, but can't you use the output from git describe for the version? Unfortunately I have to use Launchpad Recipe's supported substitution variables here, and while they do have one for the latest git-tag if I build locally this doesn't work on launchpad itself. The reason for this is that the launchpad recipe builders don't have git proper, but instead rely on bzr-git imports (the package is actually building off the launchpad bzr import of the Wine git tree merged with my packaging bzr branch). Yeah it's a bit lame, and I'll raise the issue with the launchpad folks when I see them next, but it's a pretty minor problem atm. Thanks, Scott Ritchie
Re: Daily builds of latest Git now available as Ubuntu packages
On 09/01/2011 05:05 AM, Alex Bradbury wrote: On 1 September 2011 10:50, Scott Ritchie sc...@open-vote.org wrote: For an easier user testing experience, you can now install the latest git as a convenient Ubuntu package. This seems very handy, thank you. As this seems like as good a place as any for Ubuntu packaging of wine - do you see any fix in the future for gstreamer support on Wine when compiling on 64-bit Ubuntu? The current Wine configure script (quite correctly) disables support because the installed glibconfig.h includes type definitions correct for 64-bit compilation for incorrect for 32-bit compilation. ia32-libs doesn't contain header files and there is no other package that can provide the 32-bit header. Perhaps proper multilib support in the upcoming 11.10 provides a solution? Alex I'll work on this for Oneiric beta, after I'm done with that it's possible I can backport it to Natty but no guarantees. Thanks, Scott Ritchie
Re: Testing edge cases and undocumented behavior
On 08/30/2011 04:05 AM, joerg-cyril.hoe...@t-systems.com wrote: For instance, Scott Ritchie's example is not unusual: + * If lpszStr is Null, returns how long a formatted string would be. This is a very common pattern. Probably MSDN forgot to mention it. Expect apps to use that when they find out it works. In this particular case, MSDN does mention it, however it doesn't mention all the testable behavior such as exactly when the buffer isnt modified. This is why once we test exhaustively like this our own API docs end up being better than MSDN itself. Incidentally, the tests themselves are very informative example code, and if we were trying to create a resource for developers like MSDN they'd probably have a place there. What I don't understand about Scott's patches is why there's half a dozen of them. One patch for the code, one for the tests about StrFromTimeInterval, possibly even join them. A little birdie told me that Alexandre likes small incremental patches, so I provided each test in the small increment that I noticed their need in. It does seem like the sort of thing I should combine in the future though. Thanks, Scott Ritchie
Re: buildbot status
On 08/27/2011 12:00 PM, Dan Kegel wrote: - stability problems The buildbot cluster is not ready for prime time yet. My ubuntu 11.04-based slaves tend to lock up within a day with either an OOM failure, an X livelock, or something else. So I brought an ubuntu 10.04.3 slave online and moved the buildmaster off onto its own machine; let's see what breaks next. - Slave speed Here is the complete build-and-test time (and the build time alone) for four CPUs: 54 (48) celeron @ 2.80 GHz (headless, so it's not running all tests) 17 (10) E8400 @ 3.00GHz 14 (6) Q9300 @ 2.50GHz 12 (4) i7 920 @ 2.67GHz I will probably stick with slaves that are core 2 duo or better, so patches can get fast feedback. I can get to work on backporting all the things Wine needs to the buildbot for 10.04, btw. Thanks, Scott Ritchie
Re: Testing edge cases and undocumented behavior
On 08/26/2011 12:52 AM, Francois Gouget wrote: On Thu, 25 Aug 2011, Vincent Povirk wrote: [...] * Is a Windows application likely to need this? I'd add a couple of factors that pertain to this: * Is the behavior documented by the MSDN? If yes then applications are more likely to rely on it. * Does the behavior correspond to a known usage pattern? If yes, then even if not documented in the MSDN, applications are likely to depend on it. Two examples: - APIs that take an 'LPSTR output_buffer, DWORD *buffer_size' pair of parameters. If they allow the programmer to pass 'NULL, size' where size=0 as parameters to determine the required buffer size, then you can expect applications to make use of it even if the MSDN forgot to document it. - APIs that take output parameters and will simply not fill them if the pointer is NULL instead of crashing. Incidentally, this is basically what the series of tests I wrote that prompted this discussion check. They're currently at pending in patch tracker. http://msdn.microsoft.com/en-us/library/bb759980 Of course the first thing to test is that these are are actually supported across a broad swath of the more recent Windows versions. Do you think testbot handles that nicely? Thanks, Scott Ritchie
Testing edge cases and undocumented behavior
There was a bit of a philosophical discussion on #winehackers about the merits of creating tests for functions that might be testing undefined or unimportant behavior. Windows behaves one way, we behave another, the tests measure this delta, but it's unknown if this will actually improve a real world application. There's always regression potential with any code change, however on balance adding more (fixed) tests should on average reduce that risk. Are the tests themselves evidence that a change is needed? More broadly, should we resist any change without a particular (real-world) application in hand that needs it? Or should we err on the side of testable behavior, because somewhere out there a Windows developer may have written an app the same way the test author did? Thanks, Scott Ritchie
Re: Listed package maintainers
On 07/30/2011 08:27 AM, Ben Klein wrote: I also notice the pages have been renamed (so instead of deb = ubuntu, ubuntu and debian are named correctly and unambiguously). I would like to voice my approval as former maintainer of the Debian packages, as token as that may seem at this stage. FWIW, this was for historical reasons as originally I was doing both Debian and Ubuntu packages at the same page. I stopped doing Debian packages and the page (plus all its inbound links) were still useful to Ubuntu users, so I never really changed it to anything and then sort of forgot about it. Thanks, Scott Ritchie
Re: Assining .bat and .com files with the desktop
On 08/11/2011 09:18 AM, Vincent Povirk wrote: I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me. There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing. There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types. To extend this, the relevant project is Freedesktop.org's shared-mime-info and if it can't yet tell them apart that's simply a bug. Is there a super-easy way for shared-mime-info to tell these guys apart? Thanks, Scott Ritchie
Re: [4/5] shlwapi/tests: Test for an unchanged buffer when cchMax=0 in StrFromTimeInterval
On 08/06/2011 06:59 AM, Marcus Meissner wrote: On Sat, Aug 06, 2011 at 06:54:48AM -0700, Scott Ritchie wrote: --- dlls/shlwapi/tests/string.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/dlls/shlwapi/tests/string.c b/dlls/shlwapi/tests/string.c index 68028d7..ecc58cc 100644 --- a/dlls/shlwapi/tests/string.c +++ b/dlls/shlwapi/tests/string.c @@ -615,6 +615,14 @@ static void test_StrFromTimeIntervalW(void) result-return_value, ret); ok(!strcmp(result-time_interval, szBuff), Formatted %d %d wrong\n, result-ms, result-digits); + +/* Test with 0 parameter, this should not change the buffer */ +MultiByteToWideChar(0,0,dontchange,-1,szBuffW,sizeof(szBuffW)); /sizeof(szBuffW[0]) missing. Ciao, Marcus Indeed it was. Not bad for my first attempt at C in 10 years :D Thanks, Scott Ritchie
Re: [5/5] shlwapi/tests: Test return value of StrFromTimeInterval with cchMax set to 0 (try2)
On 08/06/2011 08:38 AM, Marvin wrote: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13371 Your paranoid android. === WINEBUILD (build) === Patch failed to apply Marvin is confused about which series this belongs to since I sent it in so close to the other patchset, hence the apply failure. Testing it manually showed all passes. -Scott Ritchie
I need someone to present at the Desktop summit in my steed (Berlin)
External events are preventing me from leaving the country these next few weeks, and I'll be missing the Desktop Summit in Berlin on Monday, Aug 8th. This is the venue to talk to our friends responsible for Freedesktop.org, Gnome, KDE, Unity, and others. https://www.desktopsummit.org/program https://www.desktopsummit.org/venue The stated topic is Making Wine less broken, although this can be more constructively phrased as What Wine needs from the Desktop. Many of the recent problems with the Wine user experience have come from desktop environments breaking some of their historical windows-like way of doing things while not considering the Wine case: this conference presents us with an opportunity to engage and have Wine handled properly. Any volunteers? I'd be more than willing to talk with you personally and adapt the presentation however you like. Also if you have any particular content that you'd like to make sure gets said, post it in this thread as well :) Thanks, Scott Ritchie
Some notes from wineconf about the 1.4 release -- are we on track?
According to Alexandre... 1.4 will be out sometime in 2011 At the time of wineconf we already had several new features: animated cursors, 64-bit Gecko, native cursor themes, AcceptEx support, mono packages Goals for the 1.4 release: Successful 64-bit make test Successful 32-bit make test ;) RTL support Transparency/compositing XInput2 USB support Audio redesign DIB Engine There were also these suggestions: Addons or plugins of some sort - eg a theme for GTK-grabbing Dosbox integration - possibly using Windows versions as add-on - get rid of Winedos code Plus, of course, the general goal of making more applications work :) It seems like we're making serious progress. Have any of these stalled or become less important? Has any new big feature not listed above been done that's worth listing? Is sometime in 2011 still the best guess for 1.4's release? Thanks, Scott Ritchie
Re: Ge (Greg) van Geldorp
On 06/10/2011 01:01 PM, Paul Vriens wrote: My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. I’m very sorry that I have to inform you that Greg has passed away almost 3 weeks ago. 2 Months earlier he was diagnosed with cancer in a very aggressive form. I know he made his contribution to the Wine project. And that one of them is the WineTestBot. His passing away went so fast that he didn’t have the time to inform me all about it. What he did ask me is to make sure that the server where the WineTestBot is running on will be hosted for at least 2 more years. So we will take care of that. But I don’t know if anyone took over the administration off the server. I have the passwords, and I gave them to Maarten as well. We'll talk about this when I can. In tragic irony, I'm dealing with a father dying of very late stage cancer at the moment, so forgive me if I'm slow for a bit. Thanks, Scott Ritchie
A request about the release notes
When 1.3.19 came out it changed the build requirements for OSS support -- OSS 3 was no longer supported and OSS 4 dev libraries were required at build time. This was the changelog: New sound driver architecture for MMDevAPI. Better support for relative mouse events in DInput. Debugger support for the ARM platform. Various improvements in D3DX9. More MSVC runtime functions. Various bug fixes. At least two distros broke their OSS support as a result, since the standard update wine version but use same packaging didn't return a complete Wine anymore. In my case I only noticed when a bug report came in and I manually looked at the package build log. This sort of thing would be much less likely to happen if such a build dependency change were noted in the release notes, such as a OSS 3 no longer supported bullet point. Thanks, Scott Ritchie
Re: Tahoma Font License
On 05/25/2011 09:27 AM, Maarten Lankhorst wrote: Hi mark, 2011/5/25 Mark Page romb...@hotmail.co.uk: I am a bit confused by the Wine tahoma license: Wine Tahoma Regular ... GNU Lesser General Public License 2.1 It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. Ideally I feel it should have a creative commons license I believe Creative commons did not exist when that font was created tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed in accordance with former's license. Please do not contact Bitstream Inc. for any reason regarding this font. So just look up the original without contacting bitstream inc. ? The topic of relicensing wine fonts has come up before. Usually the discussion ends with our fonts aren't as good as you think, and you probably don't want them so don't worry about licensing. I'm not so sure it's true anymore. Symbol replacement, for instance, can actually be useful to show special characters on web pages that would otherwise come up as question marks. -Scott Ritchie
Re: Big ugly build changes might be needed for Debian/Ubuntu
On 05/22/2011 03:53 AM, Ove Kåven wrote: Den 21. mai 2011 19:38, skrev Scott Ritchie: Well now we can just Depends: wine:i386 or similar, I think. Last time I asked, they said the first multiarch implementation will not support that. The implementation cost of that would be very high (among other things, it might violate the current architecture self-containment), and the number of packages needing it is too small. Looking at the spec, it seems like Depends: wine:i386 isn't allowed, however we can create a unique package name that only exists on i386 (eg wine32), declare it Multiarch: foreign, and then have wine depend on wine32.
Re: Big ugly build changes might be needed for Debian/Ubuntu
On 05/21/2011 08:20 AM, Ove Kåven wrote: Den 19. mai 2011 20:58, skrev Scott Ritchie: A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon. Well, I don't see the problem. I've been more concerned that there's not yet any clean way to get the 64-bit package to depend on the 32-bit package, but for the build itself, it's quite trivial. (At least it was a year ago or so, and I can't imagine it has gotten worse since then.) Well now we can just Depends: wine:i386 or similar, I think. From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained. No. Very, very, far from it. The multiarch specs are created and maintained by a Ubuntu (and Debian) developer, and the motivations are purely user-oriented - making it possible, easy, and reliable for the user to do things that's currently difficult, fragile, and error-prone. But for package maintainers, life will certainly be no easier. I don't mean the multiarch change, I mean the build daemons will not allow have foreign multiarch build dependencies change, which I guess isn't a change so much as it is a property of the new system. You're quite right that multiarch proper is for users; it's something I've been demanding for a while now. Multiarch has no management implications whatsoever for the build daemons. All official Debian architectures are perfectly self-contained as they are. (Some of them currently contain cross-compiled pieces of other architectures, which would go away, but that does not concern the build daemons or the infrastructure.) Multiarch with foreign architecture build support would eliminate the self-containment, wouldn't it?
Big ugly build changes might be needed for Debian/Ubuntu
So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good. A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon. From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained. This means for bi-arch Wine, we will need to either: - Make Wine support building in pure 64-bit mode and then calling the 32-bit subsystem from a separate binary - Make a very persuasive case that Wine isn't the only package that needs to have multiple architectures at build time Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a nice to have in Wine anyway. If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now. -Scott Ritchie
Ubuntu likely to abandon HAL next cycle -- is this workable?
Consensus here seems to be to try and remove HAL from the archive. Wine still uses it, so this means we'll either need to lobby for keeping HAL or to migrate to udisks. Does udisks meet our needs? Will it work for a future USB driver? Is someone working on the migration? Thanks, Scott Ritchie
Re: Ubuntu likely to abandon HAL next cycle -- is this workable?
On 05/12/2011 07:02 PM, Alexandre Julliard wrote: Damjan Jovanovic damjan@gmail.com writes: Udisks has regressed from the portability of HAL to being Linux-only, what are we going to do for BSDs/Solaris/others? Of course even if we add udisks we'll keep the HAL support around. It's necessary for backwards compatibility, which is something we take seriously, unlike Ubuntu. The distro position is that HAL has no upstream, is unmaintained, and conflicts with udisks/upower to the point where stuff starts breaking (eg, the battery monitor gets confused and reports you have 5% and 6 hours left)
Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.
A .desktop entry pointing to a nonexistant mime type is harmless, so I'd revert the change. Indeed only a year ago Wine's .desktop entry pointed to MANY non-existant mime types. -Scott Ritchie On 05/07/2011 05:27 AM, Jerome Leclanche wrote: Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). I had a quick search through the kde sources and it seems KDE might be forcing x-win-lnk for some windows-specific behaviour. At least it's there in a bunch of tests, but no app seems to actually use it. I'll file a bug with KDE and see what else references it. Should the commit be reverted or is it a case of fix-it-upstream? J. Leclanche 2011/5/7 Ozan Türkyılmaz ozan.turkyil...@gmail.com: On Sat, 7 May 2011, Francois Gouget wrote: I'm not sure this patch is correct: on my Debian Testing machine application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which comes from the kdelibs5-data. I also found a reference to this package in the kdebase-runtime Fedora 11 runtime. I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. It's included in kdelibs package. -- Ozan, BSc, BEng
Re: Wine compatibility
On 03/23/2011 11:02 AM, Juan Lang wrote: What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened. Speculating whether MS would have done this is probably not a very useful exercise. Still, I'd say it's exceedingly improbable: 1. The cost of reviewing all the code for what might be a hack is high, and what's the benefit? Less code to maintain can't be an answer, because the 32-bit versions of Windows still need the hacks. 2. Apps written for 64-bit Windows aren't created in a vacuum: they're probably ported from a 32-bit codebase first, or 32-bit and 64-bit versions are co-developed. The same, possibly erroneous assumptions that a 32-bit application might make would therefore need to be maintained in a 64-bit version. A better place to ask questions like these might be http://blogs.msdn.com/b/oldnewthing/ --Juan Still, we're probably not going to encounter the 64-bit equivalent of If program is simcity, do this with the memory instead of that Though there are probably many newer hacks to worry about instead. --Scott Ritchie
Re: Ubuntu's next release and raising hard ulimit on ubuntu
On 03/25/2011 06:26 AM, Dan Kegel wrote: Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ? Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ). So it turns out it's not a kernel config issue per se: On 03/25/2011 06:05 PM, Tim Gardner wrote: The initial hard limit value is not a CONFIG option, so the only way it can be changed is by carrying a patch in the kernel, something I would prefer not to do. This is the macro that initializes the hard limit: include/linux/fs.h:#define INR_OPEN 1024/* Initial setting for nfile rlimits */ What is the issue with having upstart set this limit early in the boot cycle? Won't all new processes inherit the modified limit? If that's a good idea then we need to retarget the bug -Scott Ritchie
Re: [GSoC] Merge winecfg and Control Panel
On 03/23/2011 07:15 AM, Dan Kegel wrote: Also... it would be nice if there were a central commandline way of changing wine settings, kind of like 'net' is a central way of manipulating networking. I've been thinking that winecfg should have a commandline interface, too, and making it accept winetricks settings directly.Something like that would also make a good soc project. I remember proposing this idea long ago as I would have found it useful for front end user interfaces. It's what lead to the creation of the python-wine library by Christian Dannie Stroggard, which is a part of the vineyard project now. I suggest anyone having this need/considering implementing this give that a look. -Scott Ritchie
Re: Wine Gecko 1.2.0 released
On 03/15/2011 11:02 AM, Jacek Caban wrote: Hi all, The new Wine Gecko release is out and already used by Wine git version. Let me conclude shortly what has changed (more detailed updates can be found in my previous mails). It mostly means that you have to download it from Wine Sourceforge [1] and put it into the right directory [2] as always after each Gecko update. One important change is that there is msi file instead of cab file. Also starting with Wine 1.3.15, packages should be updated to depend on the new Gecko. Packagers may consider compiling Gecko themselves as building process no longer has ugly dependencies. Thanks to everyone who helped with the release! BTW, the nice thing is that accidentally we've released just after IE9. That's what I call a quick response :) Cheers, Jacek [1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0/ [2] http://wiki.winehq.org/Gecko Do you really mean 1.3.15 or do you mean the upcoming 1.3.16? -Scott
Re: Wine Gecko 1.2.0 RC1
On 03/10/2011 10:33 AM, Jacek Caban wrote: * FOR PACKAGERS * If you are interested in building the packager yourself from sources (so far I've heard about Debian and Fedora attempts to do so), everything is ready to support it now. Building instructions changed a bit after switching to use MSI files, but I've made things as easy as possible. Building the package itself is a matter of invoking one script with proper arguments. The tricky part is that Wine is needed for building, so we get circural build-time dependency. The script, however, makes sure that Wine doesn't need Gecko during compiling Gecko, so it shouldn't be a big problem to handle. Also, unless you manually set WINEPREFIX, the script created a temporary wineprefix directory, so there is nothing to worry if your ~/.wine is in broken state. It can also use Wine from its build dir if you set WINE_BUILD_DIR environment variable. Please let me know if there are more problems than need to be addressed and feel free to contact me if you have any questions. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-rc1/ Will the new Gecko be coinstallable with earlier geckos, eg for wine1.2? It would be very useful to me if this were the case (and Wine were smart enough to use the correct one depending on its version). Thanks, Scott Ritchie
Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi
On 01/27/2011 11:24 PM, Reece Dunn wrote: On 28 January 2011 01:44, Scott Ritchie sc...@open-vote.org wrote: On 01/27/2011 02:20 PM, Reece Dunn wrote: === Steps to Reproduce === Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. 1/ Build the latest version of wine with no special options -- `./configure make` 2/ Remove any previously run test result -- `find . -type f | grep .ok | xargs rm` 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` 4/ Run the tests -- `make test` This will download the gecko package and then fail in the dsound:ds3d tests with: ds3d.c:467: Test failed: buffer size changed after SetFormat() - previous size was 88200, current size is 22052 This error seems to be specific to 64-bit versions of the Ubuntu family, looking at the http://test.winehq.org/data/ results. Is this with the ia32-libs from the Wine PPA? $ dpkg -s ia32-libs Package: ia32-libs Status: install ok installed Priority: extra Section: libs Installed-Size: 143224 Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com Architecture: amd64 Version: 20090808ubuntu9 I am not using wine from the PPA, I am building it from git myself. - Reece You don't need the wine package from the PPA You do need the ia32-libs package from the Wine PPA in order to get gettext support. I recommend you do this when you're developing. -Scott
Re: Ubuntu 10.04 x86-64 test failures -- dsound:ds3d and mmdevapi
On 01/27/2011 02:20 PM, Reece Dunn wrote: === Steps to Reproduce === Machine: Ubuntu 10.04 64-bit with NVidia binary drivers. 1/ Build the latest version of wine with no special options -- `./configure make` 2/ Remove any previously run test result -- `find . -type f | grep .ok | xargs rm` 3/ Ensure running in a clean wine prefix -- `rm -rf ~/.wine` 4/ Run the tests -- `make test` This will download the gecko package and then fail in the dsound:ds3d tests with: ds3d.c:467: Test failed: buffer size changed after SetFormat() - previous size was 88200, current size is 22052 This error seems to be specific to 64-bit versions of the Ubuntu family, looking at the http://test.winehq.org/data/ results. Is this with the ia32-libs from the Wine PPA? Is 10.10 unaffected? Thanks, Scott Ritchie
Re: New winetricks 20110117-alpha: new verbs dxdiag, firefox4, ut3, hegemonygold_demo, dxdiagn, pngfilt; new svn repo, download url
On 01/17/2011 03:14 PM, Rosanne DiMesio wrote: On Mon, 17 Jan 2011 12:33:28 -0700 Vitaliy Margolen wine-de...@kievinfo.com wrote: Isn't that exactly why we marked all other scripts like this a third party unsupported tools? If you moving the same direction, then winetricks will fall into the same category - if you using it, ask Dan, don't bother asking people on forum, filing bugs, etc. We already treat winetricks like that. I know I'm constantly telling users to reinstall to a clean wineprefix with no winetricks. The winetricks wiki page tells users explicitly not to report bugs here if they have used winetricks to install native dlls, and has a link to winezeug to report bugs in winetricks itself. I don't see any of that changing. That said, I do think winetricks has become bloated. JMHO. Bloat is really just an interface problem. It's still only a few kilobytes of shell script. -Scott
Re: Wine and Fontconfig
On 01/03/2011 03:44 PM, Yaron Shahrabani wrote: Elad, an Hebrew user suggests: In several Wine apps Hebrew is displayed as square glyphs since there are no builting Hebrew glyphs in Wine's font (bug #23537). The question is why does Wine use the internal font as the default? The easier solution would be to use the system fonts as configured in fontconfig. Windows can have a custom font as well so it shouldn't cause and difficulty. This way we won't have to look for a font editing specialist that will add glyphs to wine's fonts. This problem can affect many languages as well, not just Hebrew, that lacks the required glyphs. Using the fonts from fontconfig might solve the problem and will lead to a better integreation. The fonts in Wine apps will look just like the fonts used by the rest of the apps in the system. Kind regards, YaronShahrabani Hebrew translator Yes, using fontconfig for font substitution is something Wine's needed for a while, similar issues exist for CJK fonts. What font does Windows use for Hebrew text? Ideally we could link to a free metric-compatible replacement (even if we didn't ship it with Wine); in lieu of fontconfig substitution manual registry links will be needed however. In Ubuntu I've made similar aliases for CJK fonts so they at least render text; I understand Crossover does something similar as well. Thanks, Scott Ritchie
Removal of dcom98 from winetricks?
I remember discussing this at wineconf as something we should do, but it seems there's at least one situation I've found where it still helps: http://bugs.winehq.org/show_bug.cgi?id=8780 Is it possible this is a hidden issue bleeding into other apps as well? Thanks, Scott Ritchie
Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems
On 12/10/2010 06:44 AM, Alexandre Julliard wrote: Marcus Meissner meiss...@suse.de writes: At least map_file will copy the stuff into a new anon mapping and so make it work. quake2 at least runs fully from a noexec mounted USB stick. That should be considered a bug. If you mount it noexec it's because you don't trust the code that it may contain... Should we consider doing this for individual binary files as well? Stock (non-PPA) Ubuntu already forces this through a front-end script, but I shudder to think how many existing setups we might break with the change since apps are not executable by default (unless installed by Wine, thankfully). Thanks, Scott Ritchie
Re: Packaging 1.3.7 and newer, lucid?
On 11/28/2010 08:47 AM, rozwell wrote: Scott Ritchie scott at open-vote.org writes: Uploaded as of 10 minutes ago, probably still building in launchpad. I put 1.3.7 on hold for Lucid/Karmic because I hadn't yet updated ia32-libs for them to support the newer gstreamer stuff. But it's better to release with those broken than to delay the release, so I'm gonna put 1.3.8 there too. Thanks, Scott Ritchie Greetings, Will the package delay be 1 release behind for Lucid? I'd rather stick to it for now... I'm curious if it's just a temporary situation? Maybe I could help somehow to build the newest wine packages for Lucid? rozwell That won't be necessary. I uploaded 1.3.7 first so I could sync it to the archive, then uploaded 1.3.8 afterwards. -Scott
Re: Packaging 1.3.7 and newer, lucid?
On 11/26/2010 02:39 PM, Trygve Vea wrote: Hello, I can't seem to find wine 1.3.7 / 1.3.8 packages for lucid in the ppa-repository. Does anyone know if this is on purpose? Regards Uploaded as of 10 minutes ago, probably still building in launchpad. I put 1.3.7 on hold for Lucid/Karmic because I hadn't yet updated ia32-libs for them to support the newer gstreamer stuff. But it's better to release with those broken than to delay the release, so I'm gonna put 1.3.8 there too. Thanks, Scott Ritchie
Could these changes break Wine? Fwd: gcc in natty now passes --as-needed by default to the linker
Trying to head off a problem before it's a problem... Original Message Subject: gcc in natty now passes --as-needed by default to the linker Date: Mon, 15 Nov 2010 12:26:27 +0100 From: Matthias Klose d...@ubuntu.com Reply-To: ubuntu-devel-disc...@lists.ubuntu.com To: ubuntu-devel ubuntu-devel-annou...@lists.ubuntu.com, ubuntu-devel ubuntu-de...@lists.ubuntu.com There is a second change to the linking in natty; as announced in [1], --no-add-needed/--no-copy-dt-needed-entries is passed by default, with the current gcc in natty, --as-needed is passed as well. Please see [2] for implications (runtime failures) and a list of packages which might be affected. To revert this change on a per package basis, pass --no-as-needed to the linker (-Wl,--no-as-needed in LDFLAGS). To add an explicit dependency on a library use --no-as-needed -lfoo --as-needed. Please tag bug reports with `as-needed' if you see runtime failures caused by this change (mostly unresolvable symbols referenced by plugins and ldopened objects). Matthias [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-October/000772.html [2] http://wiki.debian.org/ToolChain/DSOLinking#Onlylinkwithneededlibraries
Trying to figure out the website redirects
Why does http://www.winehq.org/todo redirect to http://wiki.winehq.org/KnownIssues ? The only list of redirects I see in the source is in include/htaccess.sample, however it lists /todo as redirecting to http://wiki.winehq.org/TodoList (which itself isn't a redirect) Are there redirects on the server that aren't in the git source? -Scott Ritchie
Developing on 64 bit Ubuntu? Add the Wine PPA for new ia32-libs that supports gstreamer codecs
The ia32-libs that ships with Ubuntu doesn't contain 32 bit libraries for all the useful codecs of gstreamer. There's enough to build Wine, but not enough to actually show a video. I've fixed this in the ia32-libs on the Wine PPA by adding _73_ new libraries to it. This is something you'll want even if you're not using the wine packages and just doing Wine development. Thankfully, ia32-libs should be finally obsolete by 11.04 with multiarch, but in the meantime we can use the PPA. I'll work on porting the ia32-libs changes to 10.04 and 9.10, but it's less of a priority. On those we have other problems (such as old GCC versions causing problems). Thanks, Scott Ritchie
Re: Compilation error with latest wine
On 11/13/2010 02:25 AM, Luca Bennati wrote: I get this: registrar.c: In function ‘DllGetClassObject’: registrar.c:747:18: error: ‘CLSID_Registrar’ undeclared (first use in this function) registrar.c:747:18: note: each undeclared identifier is reported only once for each function it appears in registrar.c: In function ‘do_register_server’: registrar.c:796:22: error: ‘CLSID_Registrar’ undeclared (first use in this function) make[1]: *** [registrar.o] Error 1 make[1]: Leaving directory `/home/luca/wine-git/dlls/atl' make: *** [dlls/atl] Error 2 make: *** Waiting for unfinished jobs I'm compiling with CFLAGS=' -g -O0 -pipe' CXXFLAGS=' -g -O0 -pipe' ./configure --prefix=/usr --sysconfdir=/etc --with-x --without-capi --without-gsm --without-icns after a make distclean What's wrong here? Works for me: http://launchpadlibrarian.net/59077812/buildlog_ubuntu-maverick-amd64.wine1.3_1.3.7-0ubuntu1~maverickppa1_BUILDING.txt.gz http://launchpadlibrarian.net/59077619/buildlog_ubuntu-maverick-i386.wine1.3_1.3.7-0ubuntu1~maverickppa1_BUILDING.txt.gz make[2]: Entering directory `/build/buildd/wine1.3-1.3.7/dlls/atl' ../../tools/makedep -C. -S../.. -T../.. atl_ax.c atl_main.c registrar.c rsrc.rc make[2]: Leaving directory `/build/buildd/wine1.3-1.3.7/dlls/atl' This is on my test PPA which has a new ia32-libs that makes the gstreamer codecs work on 64 bit, but that shouldn't affect 32 bit compiling at all. -Scott
Re: Compilation error with latest wine
On 11/13/2010 02:40 PM, Reece Dunn wrote: On 13 November 2010 22:08, Scott Ritchie sc...@... wrote: Works for me: http://launchpadlibrarian.net/59077812/buildlog_ubuntu-maverick-amd64.wine1.3_1.3.7-0ubuntu1~maverickppa1_BUILDING.txt.gz http://launchpadlibrarian.net/59077619/buildlog_ubuntu-maverick-i386.wine1.3_1.3.7-0ubuntu1~maverickppa1_BUILDING.txt.gz make[2]: Entering directory `/build/buildd/wine1.3-1.3.7/dlls/atl' ../../tools/makedep -C. -S../.. -T../.. atl_ax.c atl_main.c registrar.c rsrc.rc make[2]: Leaving directory `/build/buildd/wine1.3-1.3.7/dlls/atl' This is on my test PPA which has a new ia32-libs that makes the gstreamer codecs work on 64 bit, but that shouldn't affect 32 bit compiling at all. The issue is that atliface.idl was moved to the include directory and its content was changed. If you are doing an incremental build of wine pulling in these changes together, there is an atliface.h left over in the dlls/atl directory containing the old contents. The build is then picking that up. As a result, you need to delete the dlls/atl/atliface.h file (like Paul Virens described) and re-run ./configure. Everything will then build. Makes sense why I was unaffected, the package builds aren't incremental but from fresh archive sources. -Scott
Website copyright notice?
I was looking at the Wine wikipedia article and some jerk is nominating the logo image for deletion for copyright reasons. I wanted to correct the error and point to the license for the file, but couldn't actually find a license to point at. Have we asked this question before? Part of me just assumed the website had the same license as Wine itself (LGPL 2.1 or greater), is that the case? Thanks, Scott Ritchie
Re: Website copyright notice?
The website logo is the one in question: http://en.wikipedia.org/wiki/File:Winehq_logo_glass.png -Scott On 11/10/2010 07:50 AM, Jeremy Newman wrote: I have never bothered to license the web code as I don't really care who uses it for what. I guess that would make it a BSD license. As for the logo, I cannot speak for that. I don't remember who created the original version of the logo. The new version used on the website was created by Jon Parshall at CodeWeavers. -N On 11/10/2010 05:43 AM, Scott Ritchie wrote: I was looking at the Wine wikipedia article and some jerk is nominating the logo image for deletion for copyright reasons. I wanted to correct the error and point to the license for the file, but couldn't actually find a license to point at. Have we asked this question before? Part of me just assumed the website had the same license as Wine itself (LGPL 2.1 or greater), is that the case? Thanks, Scott Ritchie
Re:
On 11/07/2010 02:06 PM, Greg Geldorp wrote: From: Eric Pouech how come I got two different test results for the same patch ? moreover one is perfectly ok, while the other shows strange results any idea ? Yeah, that's a bit weird. The only thing I can think of is some kind of timing issue, but looking at the code that seems unlikely in this case. So basically, I don't have a clue. Ge. Updates of the Windows machines themselves? Intermittent failure of an old patch?
Re: New winetricks 20101106: mostly just bugfixes and updates
On 11/05/2010 09:50 PM, Dan Kegel wrote: Another month, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English - add amstream verb - bump firefox to 3.6.12 - fix dotnet11 install on recent wine - if user is using a 64-bit prefix, tell them how to create a 32-bit one instead. - initial 64-bit cleanup - update eadm sha1sum - update flash sha1sum - update utorrent sha1sum - don't initialize wine just to show the help menu. (Issue 182) - version shouldn't initialize Wine either (part 2 of Issue 182). Dan Kegel - update shockwave, utorrent sha1sum - added verbs l3codecx and dmsynth, and added devenum to directmusic; for winehq bug 24911 - allow continuing partial downloads if WINETRICKS_CONTINUE_DOWNLOAD is set Available on Ubuntu Wine PPA now. Was there going to be another wisotool soon? -Scott Ritchie
Re: xlive: add initial stub dll (1/3)
On 11/02/2010 01:34 PM, André Hentschel wrote: Am 02.11.2010 20:46, schrieb Austin English: On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julli...@winehq.org wrote: Austin English austinengl...@gmail.com writes: This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary: xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. Fair enough. You never know until you try and have the code in hand. For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be). @All: There are already some Projects which reimplement non-windows dlls like e.g. cuda. I totally see the reason to not integrate them into Wine, but maybe we could start a small Project hosting all that stuff at _one_ point and not spread over the www. Maybe my upcoming CE dlls will also fall into that catagory... Then we also could pack the .dll.so's up into one nsis installer, where you can select which subproject you want to install. (Maybe 32-bit and 64-bit? And possibly in some other way also for ARM?) Your opinions? From a usability perspective we're not going to be doing much good unless this happens near-automatically with a typical Wine installation. That means either including them in Wine directly or including hooks to download them when needed (this could also be done in the packaging layer) -Scott Ritchie
Surprise surprise, Tmax Window OS was a complete hoax
About a year or so ago a Korean company called Tmax was claiming to have developed a new operating system that was 100% fully Windows compatible. They also claimed to have their own office suite, web browser, and more, all developed with their own special Korean engineering to keep the license proprietary. This lead some here to justifiably worry that they were using Wine code without permission, as well as dozens of other free software projects. At the time I called it an obvious fraud. Anyway I check backed in on it and, no surprise, Tmax Soft has disavowed all knowledge of the project -- the website is dead, no news about it has appeared since the launch, and although there are several quicksearches on their main website for the product they return no results. Fortunately, with the exception of a few particularly bad tech journalists, no one seems to have been actually fooled. -Scott Ritchie
Ubuntu Package Archive is back!
When I switched Ubuntu package hosting to a launchpad PPA (away from manual .deb hosting), one thing lost was the ease of archiving old versions, since Launchpad doesn't provide this. I've written some scripts to manually copy the packages from the PPA to form a new archive and am hosting it at the old location http://wine.budgetdedicated.com/archive/ -- currently it carries all the Wine packages that have been on the Ubuntu Wine PPA since 1.3.3 or so. The main use of the archive is to aid in regression testing - installing from packages is much easier/quicker than recompiling from source, and will help you narrow down the last working/nonworking wine version before doing a proper git bisect. All I have to do is run the script every time I update the PPA with new Wine packages, and it's good. Due to server space issues, I don't plan to archive daily package builds (which is my next project). Thanks, Scott Ritchie
Removal of very very old versions from bugzilla?
Wise idea or no? If not is there at least a way to hide them from the report bug page? I'm talking about the 2001-era version numbers, before 0.9 even. -Scott Ritchie
Re: Ongoing Debian package maintenance.
On 10/12/2010 10:59 PM, Austin English wrote: On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein shackl...@gmail.com wrote: Hello everyone, My health has not improved at all since my last call for help with the Debian package management. I really need someone to take over from me, or at least some help to devise a new set of (semi-)automated build scripts. Any volunteers? Since it appears this hasn't gone anywhere, do you still need a volunteer? If so, I can, just email me the scripts/other info off list. I should step up here and offer to take over the whole thing. I'd like for the Ubuntu and Debian packages to be as identical as possible. Many of the issues are the same as well. I will admit I don't use Debian much but that can easily change. In general Ubuntu developers like for things to be done in Debian when possible, since we share so much. For instance we still don't have a package making use of Wine 1.2's 64 bit support because of the multiarch situation (which I believe is finally starting to turn around now). -Scott
Re: mono packaging, for wine packagers or anyone else who wants to follow along
On 10/01/2010 01:19 PM, Vincent Povirk wrote: Download and extract the mono 2.6.7 source tarball from http://ftp.novell.com/pub/mono/sources/mono/mono-2.6.7.tar.bz2 Use the instructions at http://wiki.winehq.org/Mono to cross-compile Mono 2.6.7 using mingw32. Tweak the script if you have to (or just want to), but consider contributing any fixes you have to make back to winezeug. I will note that packagers can do the lazy way and just follow the instructions to build a binary and then package that. I'm doing this for Ubuntu (for now), as Ubuntu doesn't provide all the Mingw libraries needed to get the package to build. So in the meantime Ubuntu users will get a binary package, and once I'm done packing up the Mingw libraries they'll get a source package that actually builds the binary properly. And thank you Vincent, this is great stuff :) -Scott Ritchie
Re: New version of exe-thumbnailer (0.7)
On 10/03/2010 07:07 PM, Nicholas van Oudtshoorn wrote: On 10/04/2010 08:39 AM, Octavian Voicu wrote: On Fri, Oct 1, 2010 at 11:18 PM, Scott Ritchie sc...@open-vote..org mailto:sc...@open-vote.org wrote: Includes much prettier icons, support for Vista icons (with icoutils 0.29.1) and more. Screenshots and a description are at: http://wiki.winehq.org/exe-thumbnailer Nice! Any plans for Kubuntu / KDE support? :) Octavian Nice! Just to note, KDE/Dolphin already has built-in support for thumnbailing exe files. (Although, in Fedora at least, it's not enabled by default; just tell dolphin to show previews for Microsoft Windows Executables. I've also got code on the KDE reviewboard that'll take care of LNK files - if it gets picked up, that'll be natively supported by KDE too... Nicholas Patches welcome :) (I think the exe-thumbnailer I got produces better images than KDE's built in stuff, fwiw) How are you parsing the LNK files for icons? Thanks Scott Ritchie
Re: mshtml.inf: Add default GeckoCabDir
On 10/01/2010 07:25 AM, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: That's a matter of trivial patch, but what would be the candidate for a path hardcode? '/usr/share/wine/gecko/' seems like the best choice since that's where most distros will install Gecko. I'd say try $datadir and then /usr/share. I would add /usr/local/share in between those two. Distro packages are supposed to go into /usr, but non distro packages go to /usr/local (eg where make install will put things). So you might want a gecko different from the distro provided one that you built yourself, for instance, but also to have it system wide.
New version of exe-thumbnailer (0.7)
Includes much prettier icons, support for Vista icons (with icoutils 0.29.1) and more. Screenshots and a description are at: http://wiki.winehq.org/exe-thumbnailer -Scott Ritchie
Re: Wine and security
On 09/28/2010 11:25 PM, Dan Kegel wrote: I keep seeing people asking about wine and security, e.g. http://bugs.winehq.org/show_bug.cgi?id=24550 or http://forum.winehq.org/viewtopic.php?t=9770 or https://answers.launchpad.net/ubuntu/+source/wine/+question/59148 ... It seems worth listing the things one can do to partially lock down wine, so I started a page at http://wiki.winehq.org/SecuringWine which is appropriately morose, yet lists a few things one could do if one really wanted to. Corrections or additions welcome. How about App Armor?
