Re: Release plans
On Mon, 13 Sep 2010, Edward Savage wrote: [...] Out of interest why are applications not considered release goals? I'm sure there is a very good reason I'd just like to know it. Just seems to me that it would be a good idea to pick a handful of very popular, but mostly ignored, applications and focus on having them work well by release (CS5 is an example I can think of immediately). One should not have to go out and buy a specific application to be able to work on a release goal. Another issue is applications that keep changing: we don't want to make Fozzle 7.0 into a release goal if one month from now all one can download is Fozzle 7.3. Applications that have neither issue could potentially be turned into release goals. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.
Re: Release plans
As a user that only uses wine for playing games built for the Windows platform what I would like the most is d3d10, d3d10.1 and d3d11. It seems that these API's are more similar between themselves than what is the difference between d3d9 and d3d10.
Re: Release plans
Looks like Alexandre must have fired up his time machine again :-) And as long as it's up and running, how about a look forward at the 1.4 release plans?
Re: Release plans
On 9/12/10 6:36 AM, Dan Kegel wrote: Looks like Alexandre must have fired up his time machine again :-) And I thought I was alone... And as long as it's up and running, how about a look forward at the 1.4 release plans? Would be nice to know what has priority for this release. I would love to see the DIB Engine be the 'deal maker'. James McKenzie
Re: Release plans
James McKenzie wrote: Dan Kegel d...@kegel.com wrote: And as long as it's up and running, how about a look forward at the 1.4 release plans? Would be nice to know what has priority for this release. I would love to see the DIB Engine be the 'deal maker'. Ain't gonna happen. Too hard, not enough manpower going into it. A more realistic goal held over from 1.2 might be DX10 support. There are several people chugging away, getting bits and pieces of that committed. I proposed a few smaller goals for 1.4 at http://wiki.winehq.org/WineReleaseCriteria : Bug 6971, the mouse problem affecting many FPS-style games, IIRC Alexandre says it would take him four weeks to clean up the XInput2 patches AcceptEx (bug 280) - needed for Warcraft III and a number of other games (Mike Kaplinskiy's real close on this, so maybe it doesn't even bear mentioning as a 1.4 goal) Antialiasing/Multisampling (Roderick's got a patch that needs a few weeks of cleanup) - Dan
Re: Release plans
On 9/12/10 12:29 PM, Dan Kegel wrote: James McKenzie wrote: Dan Kegeld...@kegel.com wrote: And as long as it's up and running, how about a look forward at the 1.4 release plans? Would be nice to know what has priority for this release. I would love to see the DIB Engine be the 'deal maker'. Ain't gonna happen. Too hard, not enough manpower going into it. Then the second goal is not going to happen either :( Emmanual Malliard? and others have stated that the DIB engine is a pre-requisite for it. A more realistic goal held over from 1.2 might be DX10 support. There are several people chugging away, getting bits and pieces of that committed. The 'missing' pieces of DX9/DX10 would be a great deal maker for 1.4 I proposed a few smaller goals for 1.4 at http://wiki.winehq.org/WineReleaseCriteria : Bug 6971, the mouse problem affecting many FPS-style games, IIRC Alexandre says it would take him four weeks to clean up the XInput2 patches This is under way by a few folks, right? AcceptEx (bug 280) - needed for Warcraft III and a number of other games (Mike Kaplinskiy's real close on this, so maybe it doesn't even bear mentioning as a 1.4 goal) I hope that Mike can solve this one. Antialiasing/Multisampling (Roderick's got a patch that needs a few weeks of cleanup) Again, this should be done quickly as well. Wine 1.4 should have something in it along the level of x64 code or a bunch of updates/fixes. I like the third one, and it is quite possible that this will be the one to make Wine 1.4 a possibility. Many folks would love to use their favorite USB 'thingy', be it a dongle, iPod, etc. that does not look like a serial device or a drive device. Anyway, I'm plugging away at Max's last DIB attempt in bug 421 to see if it breaks on the Mac Intel platform. James McKenzie - Dan
Re: Release plans
On Mon, Sep 13, 2010 at 5:29 AM, Dan Kegel d...@kegel.com wrote: James McKenzie wrote: Dan Kegel d...@kegel.com wrote: And as long as it's up and running, how about a look forward at the 1.4 release plans? Would be nice to know what has priority for this release. I would love to see the DIB Engine be the 'deal maker'. Ain't gonna happen. Too hard, not enough manpower going into it. A more realistic goal held over from 1.2 might be DX10 support. There are several people chugging away, getting bits and pieces of that committed. I proposed a few smaller goals for 1.4 at http://wiki.winehq.org/WineReleaseCriteria : Bug 6971, the mouse problem affecting many FPS-style games, IIRC Alexandre says it would take him four weeks to clean up the XInput2 patches AcceptEx (bug 280) - needed for Warcraft III and a number of other games (Mike Kaplinskiy's real close on this, so maybe it doesn't even bear mentioning as a 1.4 goal) Antialiasing/Multisampling (Roderick's got a patch that needs a few weeks of cleanup) I like the looks of this list, from a gaming point of view. An increasingly important missing feature is basic GFWL support (depends .net 3.5sp1) which I hear is getting there slowly. Would be nice to have by 1.4. Out of interest why are applications not considered release goals? I'm sure there is a very good reason I'd just like to know it. Just seems to me that it would be a good idea to pick a handful of very popular, but mostly ignored, applications and focus on having them work well by release (CS5 is an example I can think of immediately). Is there a time frame for 1.4? 1 year, 2 years, sooner?
Re: Release plans
On 09/12/2010 06:36 AM, Dan Kegel wrote: Looks like Alexandre must have fired up his time machine again :-) And as long as it's up and running, how about a look forward at the 1.4 release plans? I've discussed this idea with a lot of (non-Wine-Developer) stake-holders, and a few things came up pretty consistently. 1) Have some sort of time limit for the freeze process to start. Specific features are great for a release, but recognize that Wine gets dozens of features every month in the form of bug fixes and new applications working. Add enough of them together and you have something worthy of a release even without one big thing in particular. 2) That said, there are a few big things that would be great as release goals in and of themselves. That means substantial effort to include and polish them on behalf of core Wine developers, followed by a freeze. Possible features to name here have already been listed by others and in the wiki - DIB engine, Direct3D 10, OpenAL audio, etc. 3) Instead of a software developing perspective, we could instead release based on a QA perspective. This would mean ignoring which features were ready (or almost ready) and instead focus on the QA metrics we have - make the test suite pass everywhere (and on Windows), make sure we have some metric of test coverage, make sure the number of nonworking apps hasn't increased in some time, and so on. These ideas can all be combined, eg we don't freeze unless we have a big feature OR a whole year has passed, and once we freeze we don't release until the test suite passes on Windows, Linux, and Mac. Thanks, Scott Ritchie
Re: Release plans
On 06/20/2010 01:45 PM, wy...@volny.cz wrote: Hi, another week and Sunday gone, but this time i tried to look a bit closely to the numbers... 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks(rc1) 322 regressions -- release announcement + 3weeks(rc2) 325 regressions -- release announcement + 4weeks 326 regressions -- release announcement + 5weeks(rc3) 325 regressions -- release announcement + 6weeks(rc4) 3rd week in a row and unfortunately these numbers don't change significantly to zero. Based on these following numbers we can't even say, that we close at the same rate as new are opened. Closer look to fixing capacity or in other words what is behind -1 fixed regression for this week: +24 Newly marked, opened (new/unconfirmed) -16 Closed, resolved fixed -09 Not a regression (invalid, duplicate) -1 More IN than OUT could show that stable release is far a way. I'll note that you'll see a very similar measure when just looking at Wine bugs in general. We are, nevertheless, making progress ;) Still, I do support delaying the release until it feels like there's a substantial drop in non-deferred patches. That's the sign that tells us we've run out of easy enough release bugs/regressions to fix and may as well release. Thanks, Scott Ritchie
Re: Release plans
Hi, another week and Sunday gone, but this time i tried to look a bit closely to the numbers... 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks(rc1) 322 regressions -- release announcement + 3weeks(rc2) 325 regressions -- release announcement + 4weeks 326 regressions -- release announcement + 5weeks(rc3) 325 regressions -- release announcement + 6weeks(rc4) 3rd week in a row and unfortunately these numbers don't change significantly to zero. Based on these following numbers we can't even say, that we close at the same rate as new are opened. Closer look to fixing capacity or in other words what is behind -1 fixed regression for this week: +24 Newly marked, opened (new/unconfirmed) -16 Closed, resolved fixed -09 Not a regression (invalid, duplicate) -1 More IN than OUT could show that stable release is far a way. Another relese barometr could be Milestones 1.2: 59 bugs -- release announcement + 5weeks(rc3) 46 bugs -- release announcement + 6weeks(rc4) Decoding shows much better numbers than in case of regressions: +02 Newly marked, opened (new/unconfirmed) -11 Closed, resolved fixed -04 Not a Milestone-1.2 -13 W.
Re: Release plans
Hi, another week and Sunday gone so time for simple numbers... 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks(rc1) 322 regressions -- release announcement + 3weeks(rc2) 325 regressions -- release announcement + 4weeks 326 regressions -- release announcement + 5weeks(rc3) List of fixed bugs on rc3 release was long and impressive. Unfortunately for regressions there is a stagnation.
Re: Release plans
On 06/13/2010 10:39 AM, wy...@volny.cz wrote: Hi, another week and Sunday gone so time for simple numbers... 340 regressions-- release announcement 356 regressions-- release announcement + 1week 339 regressions-- release announcement + 2weeks(rc1) 322 regressions-- release announcement + 3weeks(rc2) 325 regressions-- release announcement + 4weeks 326 regressions-- release announcement + 5weeks(rc3) List of fixed bugs on rc3 release was long and impressive. Unfortunately for regressions there is a stagnation. Regression bugs do get fixed too but new regressions are added at the same rate. A lot of the of the newly reported regressions happened before 1.2-rc1; it looks like people are using the release candidates to test their favorite app with and report the regression they find. And that is good; just screws up the statistics ;) bye michael
Re: Release plans
Michael Stefaniuc wrote: On 06/13/2010 10:39 AM, wy...@volny.cz wrote: Hi, another week and Sunday gone so time for simple numbers... 340 regressions-- release announcement 356 regressions-- release announcement + 1week 339 regressions-- release announcement + 2weeks(rc1) 322 regressions-- release announcement + 3weeks(rc2) 325 regressions-- release announcement + 4weeks 326 regressions-- release announcement + 5weeks(rc3) List of fixed bugs on rc3 release was long and impressive. Unfortunately for regressions there is a stagnation. Regression bugs do get fixed too but new regressions are added at the same rate. A lot of the of the newly reported regressions happened before 1.2-rc1; it looks like people are using the release candidates to test their favorite app with and report the regression they find. And that is good; just screws up the statistics ;) I'll second this as there have been My application works with Wine 1.0.1, but does not with Wine-1.2-rc(x)' messages in Wine Users. Of course, this leads to bug reports. I'll start looking at regressions as soon as I can. James McKenzie
Re: Release plans
Hi, another week and Sunday gone so time for simple numbers... 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks(rc1) 322 regressions -- release announcement + 3weeks(rc2) 325 regressions -- release announcement + 4weeks Good trend from pasted weeks took a nap.
Re: Release plans
On 06/06/2010 11:34 AM, wy...@volny.cz wrote: Hi, another week and Sunday gone so time for simple numbers... 340 regressions-- release announcement 356 regressions-- release announcement + 1week 339 regressions-- release announcement + 2weeks(rc1) 322 regressions-- release announcement + 3weeks(rc2) 325 regressions-- release announcement + 4weeks As we didn't have a release last Friday shouldn't you subtract the RESOLVED and FIXED ones? Or do you 'ignore' these until possible fixes are actually committed? -- Cheers, Paul.
Re: Release plans
340 regressions-- release announcement 356 regressions-- release announcement + 1week 339 regressions-- release announcement + 2weeks(rc1) 322 regressions-- release announcement + 3weeks(rc2) 325 regressions-- release announcement + 4weeks As we didn't have a release last Friday shouldn't you subtract the RESOLVED and FIXED ones? Or do you 'ignore' these until possible fixes are actually committed? That's what i always did, i.e. there is 340 unclosed regressions, but 15 are RESOLVED, so that's where 325 comes from. BTW: I'm in process of recovery of my winetest maschine AKA WyldBOT (MOBO came back from Asus repair center).
Re: Release plans
Hi, another week and Sunday gone so time for simple numbers... 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks(rc1) 322 regressions -- release announcement + 3weeks(rc2) I think it could be even a bit better, if all the bugs we retested since friday changed their ;) I guess, that around rc11 it will look pretty good.
Re: Release plans
On Wed, May 26, 2010 at 8:46 PM, James McKenzie jjmckenzi...@earthlink.net wrote: joerg-cyril.hoe...@t-systems.com wrote: Hi, James Mckenzie wrote: Defaulting to $HOME/Desktop and $HOME/Documents is a good first step. There are more directories: Music, Videos(Movies?), Pictures that IMHO such a patch should add at the same time since that's what MS knows about as well. Austin English austinengl...@gmail.com wrote: I haven't used Tiger in ages, but at least for me on Snow Leopard, I can't delete those directories, since OSX considers them 'essential to OS function'. The likelihood of them missing is small, IMHO. Likelihood is not my friend. ls -le (or was it ls -...@?) will show the security attributes. You'll see that some of the directories have an ACL that prevents them from deletion despite the UNIX chmod flags that ls -l shows. Either will work for this. The Desktop folder has a + at the end of the directory for the current user... I agree that the additional folders have to be created, the question is WHERE? $HOME or somewhere else like .wine/drive_c/? The code you're looking for is in shell32/shellpath.c: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/shell32/shellpath.c;hb=HEAD#l2119 feel free to send a patch. I haven't gotten my mac mini fixed up for wine yet, it'll be a while before I have time to do so. -- -Austin
Re: Release plans
Hi, James Mckenzie wrote: Defaulting to $HOME/Desktop and $HOME/Documents is a good first step. There are more directories: Music, Videos(Movies?), Pictures that IMHO such a patch should add at the same time since that's what MS knows about as well. Austin English austinengl...@gmail.com wrote: I haven't used Tiger in ages, but at least for me on Snow Leopard, I can't delete those directories, since OSX considers them 'essential to OS function'. The likelihood of them missing is small, IMHO. Likelihood is not my friend. ls -le (or was it ls -...@?) will show the security attributes. You'll see that some of the directories have an ACL that prevents them from deletion despite the UNIX chmod flags that ls -l shows. What puzzled me is that in an extra login account I created on my Mac, not all of these directories were initially created. Furthermore, some of these dirs in /Users/admin/ did not have the extra access control protection against deletion, while other dirs of same name in another login had them! (I then added the ACL manually, with chmod IIRC). That's why I conjecture the existence of a create on demand Mac OS API, that possibly not everybody uses. mkdir(Videos); is enough on Linux, but perhaps there's a more OS-integrated way in MacOS? Regards, Jörg Höhle
Re: Release plans
joerg-cyril.hoe...@t-systems.com wrote: Hi, James Mckenzie wrote: Defaulting to $HOME/Desktop and $HOME/Documents is a good first step. There are more directories: Music, Videos(Movies?), Pictures that IMHO such a patch should add at the same time since that's what MS knows about as well. Austin English austinengl...@gmail.com wrote: I haven't used Tiger in ages, but at least for me on Snow Leopard, I can't delete those directories, since OSX considers them 'essential to OS function'. The likelihood of them missing is small, IMHO. Likelihood is not my friend. ls -le (or was it ls -...@?) will show the security attributes. You'll see that some of the directories have an ACL that prevents them from deletion despite the UNIX chmod flags that ls -l shows. Either will work for this. The Desktop folder has a + at the end of the directory for the current user... I agree that the additional folders have to be created, the question is WHERE? $HOME or somewhere else like .wine/drive_c/? James McKenzie
Re: Release plans
On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic damjan@gmail.com wrote: My latest patch set (http://source.winehq.org/patches/data/61966, http://source.winehq.org/patches/data/61967, http://source.winehq.org/patches/data/61968, http://source.winehq.org/patches/data/61969, http://source.winehq.org/patches/data/61970) moves all icon generation in winemenubuilder to use windowscodecs and only outputs PNG icons. This should make it pretty easy to add ICNS icon support. If you're going to test this before it gets committed, be sure to also grab http://source.winehq.org/patches/data/61940 which fixes a nasty bug in windowscodecs that corrupts many paletted ICO files. I think this was the cause of the image corruption and RGB/BGR issue Steven reported in his experiments with windowscodecs in early February. Jörg can you test whether you still get icons with black backgrounds with these patches? YAY! This makes me feel like I was actually close to understanding how it all worked ;) Thanks for all of your work on this. Since I have no clue as to how we should actually implement icns support and how well it is documented I will try to merge in my Appbundler hack once this is all merged in to head. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Release plans
On Mon, May 24, 2010 at 4:26 PM, Steven Edwards winehac...@gmail.com wrote: On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic damjan@gmail.com wrote: My latest patch set (http://source.winehq.org/patches/data/61966, http://source.winehq.org/patches/data/61967, http://source.winehq.org/patches/data/61968, http://source.winehq.org/patches/data/61969, http://source.winehq.org/patches/data/61970) moves all icon generation in winemenubuilder to use windowscodecs and only outputs PNG icons. This should make it pretty easy to add ICNS icon support. If you're going to test this before it gets committed, be sure to also grab http://source.winehq.org/patches/data/61940 which fixes a nasty bug in windowscodecs that corrupts many paletted ICO files. I think this was the cause of the image corruption and RGB/BGR issue Steven reported in his experiments with windowscodecs in early February. Jörg can you test whether you still get icons with black backgrounds with these patches? YAY! This makes me feel like I was actually close to understanding how it all worked ;) Thanks for all of your work on this. Since I have no clue as to how we should actually implement icns support and how well it is documented I will try to merge in my Appbundler hack once this is all merged in to head. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo ICNS seems like by far the easiest image file format in existence: http://en.wikipedia.org/wiki/Apple_Icon_Image Damjan
Re: Release plans
On May 24, 2010, at 9:56 AM, Damjan Jovanovic wrote: ICNS seems like by far the easiest image file format in existence: http://en.wikipedia.org/wiki/Apple_Icon_Image It's apparently slightly more complicated than that page suggests, given a simple run-length compression scheme for image data: http://ezix.org/project/wiki/MacOSXIcons -Ken
Re: Release plans
Hi, i know this statistics are not rocket science, but i'm just interested how things are getting better before release 340 regressions -- release announcement 356 regressions -- release announcement + 1week 339 regressions -- release announcement + 2weeks Long list of fixed bugs in 1.2-rc1 is also quite impressive. Thank you all!
Re: Release plans
On Thu, May 20, 2010 at 10:25 PM, Steven Edwards winehac...@gmail.com wrote: On Thu, May 20, 2010 at 4:17 PM, Steven Edwards winehac...@gmail.com wrote: I've tried with other PNGs before that we've not generated. Take a third party png, edit the Info.plist and change the icon entry to instead of pointing at the icns file point at the new Png image. Of course I've tried this on Leopard, perhaps the behaviour is different on snow leopard, I don't have a copy of it here. I am pretty sure the png support is iPod/Pad/Phone only. There may be some magic flag to allow OS X to use png rather than icns but I can't find it from google. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo My latest patch set (http://source.winehq.org/patches/data/61966, http://source.winehq.org/patches/data/61967, http://source.winehq.org/patches/data/61968, http://source.winehq.org/patches/data/61969, http://source.winehq.org/patches/data/61970) moves all icon generation in winemenubuilder to use windowscodecs and only outputs PNG icons. This should make it pretty easy to add ICNS icon support. If you're going to test this before it gets committed, be sure to also grab http://source.winehq.org/patches/data/61940 which fixes a nasty bug in windowscodecs that corrupts many paletted ICO files. I think this was the cause of the image corruption and RGB/BGR issue Steven reported in his experiments with windowscodecs in early February. Jörg can you test whether you still get icons with black backgrounds with these patches? Damjan
Fw: Re: Release plans
To the list -Forwarded Message- From: James Mckenzie jjmckenzi...@earthlink.net Sent: May 20, 2010 12:49 PM To: Damjan Jovanovic damjan@gmail.com Subject: Re: Release plans On Fri, May 14, 2010 at 12:31 PM, joerg-cyril.hoe...@t-systems.com wrote: Hi, Hi The 64-bit support is now more or less complete I hope I can finish my MCI parser patches in time. Without them, every 64bit app using MCI string commands is likely to crash (OTOH MCI commands work (those using the MCI_*_PARAMS structures)). What can Mac users expect from this release? Hopefully, conversion to Linux :-). No. BTW, I've used: TRSDOS (Model III) MS-DOS 1.0/2.0/3.0/4.0/5.0/6.0 (6.22) and updates DR-DOS 4.0/5.0 Windows 3.1, 3.11WFW, 95, 98, NT 3.51, NT 4.0, XP and Vista OS/2 Linux, Linux and more Linux (it is still user unfriendly) Mac Classic MacOSX 10.3/.4/.5 I consider MacOSX the most polished as a User Experience of all of them. Yesterday I installed an app with wine-1.1.44 on Mac OS (instead of moving it from a Linux install). It was disappointing from a user POV: - Wine created .desktop files that work on Linux but don't make sense on Mac OS. Here I've been thinking about a simple patch that would instead generate a .command file like I've described in the FAQ. OTOH, Steven Edwards IIRC once had a much more elaborate patch about better Mac OS integration, rejected last year. - In the hidden directory ~/.local/share/icons/ it created .xpm files that the Finder does not display. .png would be displayed. winemenubuilder generates .png only for 24 and 32 bits-per-pixel icons, all other resolutions get converted to .xpm. I am planning to change it to make .png's for everything, since thumbnailing .lnk files requires .png as output, and then keep .xpm only as a fallback when libpng is not installed and we're not thumbnailing. This should help you on MacOS too. Thank you. It is not a good thing that MacOSX cannot use .xpm files out of the box. I have no idea how the other packages built atop Wine behave on MacOS behave: - Kronenberg's WineBottler - doh's WineSkin - Macports build - CodeWeaver's CrossOver4Mac I assume they create nice icons that the user can click after an install. Regarding the former 2 packages, I've always been wondering why there's some sort of split in the Wine+Mac user community. Obviously the stock Wine fails to meet the Mac user's expectations, such that several people start and write something better integrated with the GUI -- but not integrated into the Wine source. From visiting the websites, I see Kronenberg's Winebottler doesn't provide source (the source link takes you to an empty repository; interestingly the LGPL requires you to provide the changed source if you distribute the software...) That's because Mike no longer makes any changes directly to the Wine code. He states that on the site (or did.) Wineskin is a complete installation wrapper that I would guess does the desktop integration itself, That's what doh123 states. It is a wrapper program that builds an exportable .app product that will start Wine and then any program that you wrap with it. He also gets the files for specific programs using winetricks. macports.org is down but http://wine.darwinports.com/ doesn't have any relevant patches, and I don't have CrossOver4Mac or a Mac to test it and see what it does. CrossOver Mac is and will remain a commercial product. They do all sorts of magic to fix the brokenness of Apple/XQuartz(s) X11's inability to display full screen and other enhancements specific to making Wine work better on the MacOSX platform. Maybe it's that Linux users generally expect the free software to be good, while Mac users generally expect good software to cost money, so when someone develops the extra bits for Wine on Mac, they either keep them to themselves or sell them? Also, I think more Wine developers use Linux than Mac, so there's less interest in fixing Wine on Mac. No. Mac users expect Mac software to just damn work. We don't want to 'tweek' and 'twist' and apply patch after patch after patch. If it don't work, out of the box, it goes. We don't have time to 'play'. So, many of us use Crossover. We pay for others to fix that which is broken. That being said, there are those of us that really like the challange of making Windows software work on the Mac as well as making Linux software work on the Mac. And we EXPECT to get paid for it. Please be aware that 'free' software NEVER IS. The phrase You get what you pay for really applies here. Again, Mac users have been conditioned to 'it works'. Wine is not, at the present time, ready for this level of acceptance and may never be. And no, Mac users are not going to switch to Linux. Some may run Ubuntu, but a vast majority unpack the system, plug it in and go to work. And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users
Re: Release plans
On Fri, May 21, 2010 at 3:47 AM, joerg-cyril.hoe...@t-systems.com wrote: And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. That's another (example of a) missing element. (Why didn't I write it? Because I was unsure where to put the #ifdef) Isn't that linking done relative to $HOME, which should resolve to /Users/xyz on Mac? That's not the problem. What I also don't know is whether I could hardcode the directories ~/Documents etc. (these already exist in my /Users/xyz, (but what about Tiger?)), or whether I ought to call some OSX API that yields the name of the dir (and possibly creates it if it does not yet exist). I'm not familiar at all with Mac APIs, but it sounds like an easy patch for somebody with a little MacOS programming knowledge. I haven't used Tiger in ages, but at least for me on Snow Leopard, I can't delete those directories, since OSX considers them 'essential to OS function'. The likelihood of them missing is small, IMHO. -- -Austin
Re: Release plans
Austin English austinengl...@gmail.com wrote: On Fri, May 21, 2010 at 3:47 AM, joerg-cyril.hoe...@t-systems.com wrote: And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. That's another (example of a) missing element. (Why didn't I write it? Because I was unsure where to put the #ifdef) Isn't that linking done relative to $HOME, which should resolve to /Users/xyz on Mac? That's not the problem. What I also don't know is whether I could hardcode the directories ~/Documents etc. (these already exist in my /Users/xyz, (but what about Tiger?)), or whether I ought to call some OSX API that yields the name of the dir (and possibly creates it if it does not yet exist). I'm not familiar at all with Mac APIs, but it sounds like an easy patch for somebody with a little MacOS programming knowledge. I haven't used Tiger in ages, but at least for me on Snow Leopard, I can't delete those directories, since OSX considers them 'essential to OS function'. The likelihood of them missing is small, IMHO. Correct. However, you are free to create new directories for these functions and use them, except the Desktop. The location of these files could be changed but that is mostly beyond most Mac Users. Defaulting to $HOME/Desktop and $HOME/Documents is a good first step. James McKenzie
Fw: Re: Release plans
To the list. -Forwarded Message- From: James Mckenzie jjmckenzi...@earthlink.net Sent: May 21, 2010 8:20 AM To: joerg-cyril.hoe...@t-systems.com Subject: Re: Release plans joerg-cyril.hoe...@t-systems.com wrote: And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. That's another (example of a) missing element. (Why didn't I write it? Because I was unsure where to put the #ifdef) Isn't that linking done relative to $HOME, which should resolve to /Users/xyz on Mac? That's not the problem. What I also don't know is whether I could hardcode the directories ~/Documents etc. AFIAK, I would not hard code them, but give a default of $HOME/Documents and $HOME/Desktop (this would allow users to change the directory, maybe through the registry or through environment variables. (these already exist in my /Users/xyz, but what about Tiger? I don't think there are many Intel Macs running Tiger anymore and Darwine is completely dead. or whether I ought to call some OSX API that yields the name of the dir (and possibly creates it if it does not yet exist). This is a third idea that we may want to look at. I'm not familiar at all with Mac APIs, but it sounds like an easy patch for somebody with a little MacOS programming knowledge. Hmmm. What can Mac users expect from this release? Hopefully, conversion to Linux :-). Actually, one day I was fed up with the Gnome and KDE4 GUIs, so I started looking for something else. The Mac Mini with NVidia came out right at that time: extremely silent (except for the CD-ROM), excellent graphics (by far better than any onboard Intel I knew previously) and it's a UNIX. My feelings exactly. If Gnome and KDE were so good, why are there other Linux windows management tools? James McKenzie
Re: Release plans
On Fri, May 14, 2010 at 12:31 PM, joerg-cyril.hoe...@t-systems.com wrote: Hi, Hi The 64-bit support is now more or less complete I hope I can finish my MCI parser patches in time. Without them, every 64bit app using MCI string commands is likely to crash (OTOH MCI commands work (those using the MCI_*_PARAMS structures)). What can Mac users expect from this release? Hopefully, conversion to Linux :-). Yesterday I installed an app with wine-1.1.44 on Mac OS (instead of moving it from a Linux install). It was disappointing from a user POV: - Wine created .desktop files that work on Linux but don't make sense on Mac OS. Here I've been thinking about a simple patch that would instead generate a .command file like I've described in the FAQ. OTOH, Steven Edwards IIRC once had a much more elaborate patch about better Mac OS integration, rejected last year. - In the hidden directory ~/.local/share/icons/ it created .xpm files that the Finder does not display. .png would be displayed. winemenubuilder generates .png only for 24 and 32 bits-per-pixel icons, all other resolutions get converted to .xpm. I am planning to change it to make .png's for everything, since thumbnailing .lnk files requires .png as output, and then keep .xpm only as a fallback when libpng is not installed and we're not thumbnailing. This should help you on MacOS too. I have no idea how the other packages built atop Wine behave on MacOS behave: - Kronenberg's WineBottler - doh's WineSkin - Macports build - CodeWeaver's CrossOver4Mac I assume they create nice icons that the user can click after an install. Regarding the former 2 packages, I've always been wondering why there's some sort of split in the Wine+Mac user community. Obviously the stock Wine fails to meet the Mac user's expectations, such that several people start and write something better integrated with the GUI -- but not integrated into the Wine source. From visiting the websites, I see Kronenberg's Winebottler doesn't provide source (the source link takes you to an empty repository; interestingly the LGPL requires you to provide the changed source if you distribute the software...), Wineskin is a complete installation wrapper that I would guess does the desktop integration itself, macports.org is down but http://wine.darwinports.com/ doesn't have any relevant patches, and I don't have CrossOver4Mac or a Mac to test it and see what it does. Maybe it's that Linux users generally expect the free software to be good, while Mac users generally expect good software to cost money, so when someone develops the extra bits for Wine on Mac, they either keep them to themselves or sell them? Also, I think more Wine developers use Linux than Mac, so there's less interest in fixing Wine on Mac. And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. That's another (example of a) missing element. (Why didn't I write it? Because I was unsure where to put the #ifdef) Isn't that linking done relative to $HOME, which should resolve to /Users/xyz on Mac? Regards, Jörg Höhle Regards Damjan Jovanovic
Re: Release plans
On Thu, May 20, 2010 at 3:08 PM, Damjan Jovanovic damjan@gmail.com wrote: winemenubuilder generates .png only for 24 and 32 bits-per-pixel icons, all other resolutions get converted to .xpm. I am planning to change it to make .png's for everything, since thumbnailing .lnk files requires .png as output, and then keep .xpm only as a fallback when libpng is not installed and we're not thumbnailing. This should help you on MacOS too. I have no idea how the other packages built atop Wine behave on MacOS behave: - Kronenberg's WineBottler - doh's WineSkin - Macports build - CodeWeaver's CrossOver4Mac I assume they create nice icons that the user can click after an install. I have a hacked version in the Bordeaux tree that uses sips to create icns icons and working Application bundles. If they have time, Austin or Tom can send it along for your review if your interested. The 'right' solution would be to figure out how to make them happy with png's or write a WIC encoder/filter/whatever for icns, I just don't have the time these days. Without getting off on to a long rant, I 'hacked' our version call sips on OS X to convert the images to icns.I was never able to get App bundles to want to play nice with the png images winemenubuilder spits out but it works most of the time. Since it's derived LGPL code we are happy to share, though it really is a hack and I am sure Alexandre would not want it in the tree, even for the new release. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Release plans
On Thu, May 20, 2010 at 3:44 PM, Steven Edwards winehac...@gmail.comwrote: I have a hacked version in the Bordeaux tree that uses sips to create icns icons and working Application bundles. If they have time, Austin or Tom can send it along for your review if your interested. The 'right' solution would be to figure out how to make them happy with png's or write a WIC encoder/filter/whatever for icns, I just don't have the time these days. Without getting off on to a long rant, I 'hacked' our version call sips on OS X to convert the images to icns.I was never able to get App bundles to want to play nice with the png images winemenubuilder spits out but it works most of the time. Since it's derived LGPL code we are happy to share, though it really is a hack and I am sure Alexandre would not want it in the tree, even for the new release. Sorry for the double spam, I thought I did not have a copy of the code handy. Here is the hacked patch, it's quite nasty as it forks for every image is processes so it takes a while to generate the icons. There was a bit of a race condition so I further hacked it by sleeping but it got the job done. As I said, figuring out why Appbundles did not want to play nice with the png images would be great. I suspect png image AppBundle support really only works on iDevices and not full OS X and if so, we just need a better way to spitout/convert to icns images. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo wine_menubuilder Description: Binary data
Re: Release plans
On Thu, May 20, 2010 at 9:51 PM, Steven Edwards winehac...@gmail.com wrote: On Thu, May 20, 2010 at 3:44 PM, Steven Edwards winehac...@gmail.com wrote: I have a hacked version in the Bordeaux tree that uses sips to create icns icons and working Application bundles. If they have time, Austin or Tom can send it along for your review if your interested. The 'right' solution would be to figure out how to make them happy with png's or write a WIC encoder/filter/whatever for icns, I just don't have the time these days. Without getting off on to a long rant, I 'hacked' our version call sips on OS X to convert the images to icns.I was never able to get App bundles to want to play nice with the png images winemenubuilder spits out but it works most of the time. Since it's derived LGPL code we are happy to share, though it really is a hack and I am sure Alexandre would not want it in the tree, even for the new release. Sorry for the double spam, I thought I did not have a copy of the code handy. Here is the hacked patch, it's quite nasty as it forks for every image is processes so it takes a while to generate the icons. There was a bit of a race condition so I further hacked it by sleeping but it got the job done. As I said, figuring out why Appbundles did not want to play nice with the png images would be great. I suspect png image AppBundle support really only works on iDevices and not full OS X and if so, we just need a better way to spitout/convert to icns images. Thanks Everything in the .png generation looks bog standard, but maybe MacOS doesn't like our PNG comment. Try remove that ppng_set_text call in winemenubuilder's SaveIconResAsPNG and see if it helps? -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo Damjan
Re: Release plans
On Thu, May 20, 2010 at 4:13 PM, Damjan Jovanovic damjan@gmail.com wrote: Everything in the .png generation looks bog standard, but maybe MacOS doesn't like our PNG comment. Try remove that ppng_set_text call in winemenubuilder's SaveIconResAsPNG and see if it helps? I've tried with other PNGs before that we've not generated. Take a third party png, edit the Info.plist and change the icon entry to instead of pointing at the icns file point at the new Png image. Of course I've tried this on Leopard, perhaps the behaviour is different on snow leopard, I don't have a copy of it here. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Release plans
On Thu, May 20, 2010 at 4:17 PM, Steven Edwards winehac...@gmail.com wrote: I've tried with other PNGs before that we've not generated. Take a third party png, edit the Info.plist and change the icon entry to instead of pointing at the icns file point at the new Png image. Of course I've tried this on Leopard, perhaps the behaviour is different on snow leopard, I don't have a copy of it here. I am pretty sure the png support is iPod/Pad/Phone only. There may be some magic flag to allow OS X to use png rather than icns but I can't find it from google. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Release plans
Hi, some time passed and because statistics are somewhat popular here, i did one ;) 340 regressions -- release announcement 356 regressions -- release announcement + 1week So we are not converging... Will there be at least an effort to fix all the regression or should i go and crawl through them and nominate them as milestone 1.2? Don't take this bad, just a question ;) I hope that fixing them all is the right way, which will save me time with nominating.
Re: Release plans
Hi, some time passed and because statistics are somewhat popular here, i did one ;) 340 regressions -- release announcement 356 regressions -- release announcement + 1week Not a good statistic, but maybe we caused a few folks to decide to submit overdue regressions now that Wine 1.2 was announced. I hope that fixing them all is the right way, which will save me time with nominating. +1 to this thought. Fixing now is better than fixing later... James McKenzie
Re: Release plans
Hey Brian, Jeremy - do you have a copy of the real press release we did for 1.0? I dug around looking for it and couldn't find it. Looks like we never properly posted it on WineHQ. It did get picked up by quite a few news sites, but Google isn't finding it. Scott / Edward - when 1.0 came out, Jeremy had the PR firm that writes copy for Codeweavers put together a press release for Wine. It was pretty good and fairly polished. I'm not sure if having them do it again would be an option. Also, I think Wine 1.0 was coordinated with a release of Crossover 7.0. I can't find anything on that release, but we're certainly happy to put together another one for Wine 1.2. I've CC'd Jon Parshall, as he's the guy that'll get to do it. Cheers, Jeremy
Re: Release plans
On Sat, May 15, 2010 at 1:11 AM, Jeremy White jwh...@codeweavers.com wrote: I can't find anything on that release, but we're certainly happy to put together another one for Wine 1.2. I've CC'd Jon Parshall, as he's the guy that'll get to do it. Could you link us to a copy of the 1.0 one? Some one professional doing the release would be really cool. If that is sorted I really want to do a short showcase of applications that do run well now under Wine (and maybe Crossover? ie Chrome) with a blurb and screen shot for them. A static page that can be linked to for people who want to quickly check out the progress instead of trudging through the appdb.
Re: Release plans
Edward Savage wrote: On Sat, May 15, 2010 at 1:11 AM, Jeremy White jwh...@codeweavers.com wrote: I can't find anything on that release, but we're certainly happy to put together another one for Wine 1.2. I've CC'd Jon Parshall, as he's the guy that'll get to do it. Could you link us to a copy of the 1.0 one? Um, no; that's what I meant when I said I couldn't find anything on it grin. In fact, our PR firm is questioning our sanity - are we really sure we did a release? I'm not sure a release is all that advantageous; it goes over the wire to overwhelmed newsprint reporters who usually ignore it. An announcement is quite likely to be picked up on places like Slashdot and Digg, and that then tends to spur internet buzz far and wide. So...an announcement may be all we really need. Cheers, Jeremy
Re: Release plans
On Wed, 12 May 2010, Alexandre Julliard wrote: Scott Ritchie sc...@open-vote.org writes: On 05/09/2010 05:00 PM, Alexandre Julliard wrote: We definitely need a release changelog, yes. It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. Sure, that's the press release, we should have one too, but it's a different thing. A changelog would be a detailed description of changes that matter from a user point of view. It would list for instance new builtin programs, new configuration options, new behaviors, new system dependencies, backwards compatibility concerns, etc. Isn't that more a release notes document? So we'd have: * Press Release Announcing the new Wine to the world at large. Must be readable by people who have never heard of Wine before. * Release notes A user friendly and high-level description what's new and what's changed. * Changelog A detailed description of what's changed from a developper perspective, that is the usual list of commit messages. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: Release plans
On 05/09/2010 05:00 PM, Alexandre Julliard wrote: Edward Savage epss...@gmail.com writes: On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard julli...@winehq.org wrote: Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. Would it be worthwhile to put together some sort of release announcement detailing changes and improvements in Wine between 1 and 1.2? Some thing similar to what other projects release that tech sites can pickup and talk about. Maybe even a more formal press release style document. We definitely need a release changelog, yes. It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. I've created a rough skeleton of things to have here: http://wiki.winehq.org/Wine1.2Announcement I'm very busy at the Ubuntu Developer Summit at the moment but I'll put some good work into it soon. Thanks, Scott Ritchie
Re: Release plans
On Thu, May 13, 2010 at 1:08 AM, Scott Ritchie sc...@open-vote.org wrote: It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. I've created a rough skeleton of things to have here: http://wiki.winehq.org/Wine1.2Announcement I'm very busy at the Ubuntu Developer Summit at the moment but I'll put some good work into it soon. I was strongly alluding to this. I am not a journalist though I did get forced to take a course in it for a university elective so I know the basics and I am a big fan of writing. I have been considering the best way to frame Wine to get the most attention and new users. I will update that wiki page with my ideas and start fleshing out some blocks of content. I have almost no written work for people to see beyond some stories I wrote for an as-yet unreleased copy of WWN. http://home.bluesata.com/WineWWN/WineHQ/wwn/362 Still I think I'd be up to the task to write some thing worthwhile.
Re: Release plans
On Wed, May 12, 2010 at 9:29 AM, Edward Savage epss...@gmail.com wrote: On Thu, May 13, 2010 at 1:08 AM, Scott Ritchie sc...@open-vote.org wrote: It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. Jeremy - do you have a copy of the real press release we did for 1.0? I dug around looking for it and couldn't find it. Looks like we never properly posted it on WineHQ. It did get picked up by quite a few news sites, but Google isn't finding it. Scott / Edward - when 1.0 came out, Jeremy had the PR firm that writes copy for Codeweavers put together a press release for Wine. It was pretty good and fairly polished. I'm not sure if having them do it again would be an option. Also, I think Wine 1.0 was coordinated with a release of Crossover 7.0. Also, what would be really good would be to provide some contact information for people that can be used by the press to ask some simple questions about the release. It'd be good to have a European contact and a US one. However, be prepared to actually get called and be available by email to answer questions. News sites like to turn articles around in a matter of hours, so it needs a tiny bit of attention. PS - Hung out with Mike McCormack on Monday. It was good to see him again. -Brian
Re: Release plans
On Wed, May 12, 2010 at 11:27 AM, Brian Vincent brian.vinc...@gmail.com wrote: Also, what would be really good would be to provide some contact information for people that can be used by the press to ask some simple questions about the release. It'd be good to have a European contact and a US one. However, be prepared to actually get called and be available by email to answer questions. News sites like to turn articles around in a matter of hours, so it needs a tiny bit of attention. There's pr...@winehq.org, which gets sent to a few people. See http://bugs.winehq.org/show_bug.cgi?id=20603 That doesn't have phone numbers, though. However, between all of us, I'm sure someone will see the email fairly quickly. -- -Austin
Re: Release plans
Scott Ritchie sc...@open-vote.org writes: On 05/09/2010 05:00 PM, Alexandre Julliard wrote: We definitely need a release changelog, yes. It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. Sure, that's the press release, we should have one too, but it's a different thing. A changelog would be a detailed description of changes that matter from a user point of view. It would list for instance new builtin programs, new configuration options, new behaviors, new system dependencies, backwards compatibility concerns, etc. You can't put that sort of things in the press release. -- Alexandre Julliard julli...@winehq.org
Re: Release plans
On 05/09/2010 05:00 PM, Alexandre Julliard wrote: Edward Savage epss...@gmail.com writes: On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard julli...@winehq.org wrote: Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. Would it be worthwhile to put together some sort of release announcement detailing changes and improvements in Wine between 1 and 1.2? Some thing similar to what other projects release that tech sites can pickup and talk about. Maybe even a more formal press release style document. We definitely need a release changelog, yes. It seems to me what we really want is more than a changelog but a proper release announcement. I want a journalist who has hardly heard of Wine to read the page and understand what we've done and why it's great. We need BOTH a change log and the press release. The Press release needs to highlight the changes like adding Windows-on-Windows 64 code and the ability to work with .NET 2.0. The Changelog should be extremely detailed and directed at the user to advise what was fixed and what is still broken or will be broken by using this release. I've created a rough skeleton of things to have here: http://wiki.winehq.org/Wine1.2Announcement I'm very busy at the Ubuntu Developer Summit at the moment but I'll put some good work into it soon. Thank you for starting work on the announcement. The changelog will be a much more lengthy work. James McKenzie
Re: Release plans
Hin-Tak Leung hintak_le...@yahoo.co.uk writes: Alexandre Julliard wrote: Ben Klein shackl...@gmail.com writes: I'm more interested to know in the status of WoW64 in Wine. Can 64bit and 32bit Wine be installed sensibly and concurrently? Yes, everything should work as expected now. Please test it. The last time I checked it was possible to re-use an old wineprefix (created by 32-bit wine under x86_64 platform) with 64-bit wine - is it still the case? My .wine is a bit big and I'd hate to have to re-create it... :-(. You can use a 32-bit prefix with 64-bit Wine, but of course only in 32-bit mode, you won't be able to run 64-bit apps with it. -- Alexandre Julliard julli...@winehq.org
Re: Release plans
Alexandre Julliard wrote: Ben Klein shackl...@gmail.com writes: I'm more interested to know in the status of WoW64 in Wine. Can 64bit and 32bit Wine be installed sensibly and concurrently? Yes, everything should work as expected now. Please test it. The last time I checked it was possible to re-use an old wineprefix (created by 32-bit wine under x86_64 platform) with 64-bit wine - is it still the case? My .wine is a bit big and I'd hate to have to re-create it... :-(. Hin-Tak
Re: Release plans
--- On Mon, 10/5/10, Alexandre Julliard julli...@winehq.org wrote:
The last time I checked it was possible to re-use an
old wineprefix
(created by 32-bit wine under x86_64 platform) with
64-bit wine - is
it still the case? My .wine is a bit big and I'd hate
to have to
re-create it... :-(.
I meant to write wasn't possible . Sorry about that.
You can use a 32-bit prefix with 64-bit Wine, but of course
only in
32-bit mode, you won't be able to run 64-bit apps with it.
It is all a bit confusing - see
(https://bugzilla.redhat.com/show_bug.cgi?id=533806) I think the last time I
tried both, I did encounter the problem with
'/home/myuzer/.wine' is a 32-bit prefix, it cannot be used with 64-bit
Wine.
I think a wiki/FAQ could be useful - there is an FAQ somewhere which says one
should use a different prefix for 32-bit wine vs 64-bit wine on platforms which
can do both. My concern is that I have a fairly big ${HOME}/.wine and I'd
prefer to continue to use it, or at least it doesn't get messed up if I switch
to 64-bit wine.
Re: Release plans
Ben Klein shackl...@gmail.com writes: I'm more interested to know in the status of WoW64 in Wine. Can 64bit and 32bit Wine be installed sensibly and concurrently? Yes, everything should work as expected now. Please test it. -- Alexandre Julliard julli...@winehq.org
Re: Release plans
Tom Wickline twickl...@gmail.com writes: I thought the code freeze, RC cycle would be more like three months not three releases, e.g six weeks. But I'm 100% sure AJ knows best. :) Nobody said it can't be three months. It will last as long as good fixes keep pouring in. In practice after 1-2 months we usually run out of bugs that can be reasonably fixed; at that point it wouldn't make sense to hold the release for another month to get 3 extra fixes. And like last time, I'm planning to make rc releases on a weekly schedule, so we should get plenty of them. -- Alexandre Julliard julli...@winehq.org
Re: Release plans
On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard julli...@winehq.org wrote: Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. Would it be worthwhile to put together some sort of release announcement detailing changes and improvements in Wine between 1 and 1.2? Some thing similar to what other projects release that tech sites can pickup and talk about. Maybe even a more formal press release style document. If not I feel it might be good to have a page, nicely formatted with graphics, that listed some applications that run as-native that people not using Wine can try so that they become familiar with the application. We could easily compile a list of 10-15 popular platinum applications that those who discredit Wine would be surprised run well. A small blurb and some nice screen shots of each application with links to their respective Appdb and Wikipedia entries would be good. I am volunteering to organise some thing like this if wanted but it'd have to be some thing people were comfortable with and like the idea of.
Re: Release plans
Edward Savage epss...@gmail.com writes: On Sun, May 9, 2010 at 4:42 AM, Alexandre Julliard julli...@winehq.org wrote: Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. Would it be worthwhile to put together some sort of release announcement detailing changes and improvements in Wine between 1 and 1.2? Some thing similar to what other projects release that tech sites can pickup and talk about. Maybe even a more formal press release style document. We definitely need a release changelog, yes. -- Alexandre Julliard julli...@winehq.org
Re: Release plans
On Sat, May 8, 2010 at 1:42 PM, Alexandre Julliard julli...@winehq.orgwrote: Folks, The 64-bit support is now more or less complete, and we have most of the fancy new icons, so it's time to think about the next stable release. Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. As usual the code freeze will become more and more drastic as we get closer to release, so if you have major changes to make, now is pretty much the last minute. I'd encourage everyone to look through the list of nominated 1.2 bugs, and also to check the regression reports for anything that might be in your area. We should strive to have as few regressions from 1.0 as possible, so regressions fixes will have priority during code freeze. And of course changes that don't impact the code, like translations or test fixes, can go in until quite late. -- Alexandre Julliard julli...@winehq.org What do you mean by the 64-bit support being more or less complete?
Re: Release plans
Alexandre Julliard wrote: Folks, The 64-bit support is now more or less complete, and we have most of the fancy new icons, so it's time to think about the next stable release. Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. As usual the code freeze will become more and more drastic as we get closer to release, so if you have major changes to make, now is pretty much the last minute. I'd encourage everyone to look through the list of nominated 1.2 bugs, and also to check the regression reports for anything that might be in your area. We should strive to have as few regressions from 1.0 as possible, so regressions fixes will have priority during code freeze. And of course changes that don't impact the code, like translations or test fixes, can go in until quite late. AJ: I would be nice to include the URL as well for the 1.2 buglist. James McKenzie
Re: Release plans
On Sat, May 8, 2010 at 3:31 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Alexandre Julliard wrote: Folks, The 64-bit support is now more or less complete, and we have most of the fancy new icons, so it's time to think about the next stable release. Unless some major problems come up, 1.1.44 will be the last of the 1.1.x series. The next release will be 1.2-rc1, which will mark the beginning of the code freeze. This should result in a 1.2 final sometime in June. As usual the code freeze will become more and more drastic as we get closer to release, so if you have major changes to make, now is pretty much the last minute. I'd encourage everyone to look through the list of nominated 1.2 bugs, and also to check the regression reports for anything that might be in your area. We should strive to have as few regressions from 1.0 as possible, so regressions fixes will have priority during code freeze. And of course changes that don't impact the code, like translations or test fixes, can go in until quite late. AJ: I would be nice to include the URL as well for the 1.2 buglist. It's the first link on the tasklist in bugzilla: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Winetarget_milestone=1.2.0order=bugs.bug_severity -- -Austin
Re: Release plans
On Sun, May 9, 2010 at 4:34 AM, Austin English austinengl...@gmail.comwrote: It's the first link on the tasklist in bugzilla: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Winetarget_milestone=1.2.0order=bugs.bug_severity -- -Austin Three releases to fix 88 nasty bugs? -- Tom
re: Release plans
Tom Wickline wrote: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Winetarget_milestone=1.2.0 Three releases to fix 88 nasty bugs? The sad fact is that it would take a lot more than that to fix them all, and it probably doesn't make sense to hold up the release until it's perfect. We probably want to update http://wiki.winehq.org/WineReleaseCriteria with the current release criteria. Some other interesting searches: Bugs marked as 'regression' (340!): http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords_type=allwordskeywords=regression Bugs marked 'bisected': http://bugs.winehq.org/buglist.cgi?quicksearch=bisected Anything A.F. has analyzed : http://bugs.winehq.org/buglist.cgi?product=Winebug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemaillongdesc2=1emailtype2=substringemail2=focht - Dan
Re: Release plans
On Sun, May 9, 2010 at 7:02 AM, Dan Kegel d...@kegel.com wrote: Tom Wickline wrote: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Winetarget_milestone=1.2.0 Three releases to fix 88 nasty bugs? The sad fact is that it would take a lot more than that to fix them all, and it probably doesn't make sense to hold up the release until it's perfect. We probably want to update http://wiki.winehq.org/WineReleaseCriteria with the current release criteria. Some other interesting searches: Bugs marked as 'regression' (340!): http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords_type=allwordskeywords=regression Bugs marked 'bisected': http://bugs.winehq.org/buglist.cgi?quicksearch=bisected Anything A.F. has analyzed : http://bugs.winehq.org/buglist.cgi?product=Winebug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemaillongdesc2=1emailtype2=substringemail2=focht - Dan I thought the code freeze, RC cycle would be more like three months not three releases, e.g six weeks. But I'm 100% sure AJ knows best. :) -- Tom
Re: Release plans
While we're linking to bug lists, this one seems most interesting to me: http://bit.ly/bfOHK5 That's the list of major regressions introduced since 1.0-rc1. Bug 13891 in particular will make us look bad if it's not fixed before 1.2. A lot of apps (as I understand it, any app that does it properly) can't open url's anymore in the native browser, and this worked in 1.0.
Re: Release plans
Vincent Povirk wrote: While we're linking to bug lists, this one seems most interesting to me: http://bit.ly/bfOHK5 That's the list of major regressions introduced since 1.0-rc1. Bug 13891 in particular will make us look bad if it's not fixed before 1.2. A lot of apps (as I understand it, any app that does it properly) can't open url's anymore in the native browser, and this worked in 1.0. Vincent: +1. This is will be reported again and again. James McKenzie
Re: Release plans
Vincent Povirk wrote: While we're linking to bug lists, this one seems most interesting to me: http://bit.ly/bfOHK5 That's the list of major regressions introduced since 1.0-rc1. Bug 13891 in particular will make us look bad if it's not fixed before 1.2. A lot of apps (as I understand it, any app that does it properly) can't open url's anymore in the native browser, and this worked in 1.0. Actually, when I read through the report, it broke in 1.0-rc4 but worked in 0.9.52. That is one old bug and aggravating too. James McKenzie
Re: Release plans
Actually, when I read through the report, it broke in 1.0-rc4 but worked in 0.9.52. That is one old bug and aggravating too. You're right, so it didn't work in 1.0. That's.. that might actually be worse.
Re: Release plans
On Sat, May 8, 2010 at 7:16 PM, Vincent Povirk madewokh...@gmail.comwrote: While we're linking to bug lists, this one seems most interesting to me: http://bit.ly/bfOHK5 That's the list of major regressions introduced since 1.0-rc1. ... What criteria did you use to build that list? There's a bunch of recent breakage in cursor support that make a lot of games very difficult to use. Erich Hoover ehoo...@mines.edu
Re: Release plans
On Sat, May 8, 2010 at 8:43 PM, Erich Hoover ehoo...@mines.edu wrote: On Sat, May 8, 2010 at 7:16 PM, Vincent Povirk madewokh...@gmail.com wrote: While we're linking to bug lists, this one seems most interesting to me: http://bit.ly/bfOHK5 That's the list of major regressions introduced since 1.0-rc1. ... What criteria did you use to build that list? There's a bunch of recent breakage in cursor support that make a lot of games very difficult to use. Version = 1.0-rc1 Severity = major Keywords include regression
Re: Release plans
Vincent Povirk wrote: Actually, when I read through the report, it broke in 1.0-rc4 but worked in 0.9.52. That is one old bug and aggravating too. You're right, so it didn't work in 1.0. That's.. that might actually be worse. Vincent: This should be on the 1.2 todo list. This really needs to be fixed and is/was the topic of a thread on the Wine-Users list recently. James McKenzie
Re: Release plans
2010/5/9 Sir Gallantmon (ニール・ゴンパ) ngomp...@gmail.com: On Sat, May 8, 2010 at 1:42 PM, Alexandre Julliard julli...@winehq.org wrote: Folks, The 64-bit support is now more or less complete, and we have most of the fancy new icons, so it's time to think about the next stable release. What do you mean by the 64-bit support being more or less complete? I'm more interested to know in the status of WoW64 in Wine. Can 64bit and 32bit Wine be installed sensibly and concurrently?
Re: Release plans
On 10/1/05, Francois Gouget [EMAIL PROTECTED] wrote: On Sat, 1 Oct 2005, Brian Vincent wrote: On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Question is, how do I convey updates to the documentation to you guys? Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed WineHQ's CVS page should be updated with instructions on how to get the documentation: http://www.winehq.com/site/cvs I see this is done now. Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too). When Newman gets a chance it would be a good idea to sync the FAQ currently on WineHQ with the current FAQ on source forge. There is a Q/A in the FAQ that points out how to get the Doc's. -Tom
Re: Release plans
On Mon, 03 Oct 2005 19:15:20 +0200, Holly Bostick wrote: As far as I know, Gentoo (along with many other distros) cleaned up their act w.r.t wine several months ago (when Mike Hearn, I believe, got the various maintainers to *pay attention* to Wine development, rather than just assuming that everything built the same as it had previously month after month-- when it couldn't because so many changes were going on). While I'd love to take credit for that, it was actually Vincent Beron who beat up the Gentoo guys. I just bitched about it a lot :) thanks -mike
Re: Release plans
Holly Bostick wrote: If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process. Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so Is anyone building wine for Debian anymore? //Jakob deb http://wine.sourceforge.net/apt/ binary/
Re: Release plans
James Liggett wrote: Molle Bestefich wrote: There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/. That's odd...I got IDA 4.8 demo to install and work without any problems at all. Perhaps something broke recently? Must have. Recently? Not so sure. I've tweaked the docs to reflect this (point to idafree 3.85b, which is the only ida that works right now - sort of, and GoVest) in the meantime. What sort of errors do you get? The installer can't create it's installation directory. Creating the directory manually does not help. Creating the directory it would've created - manually, then pointing the installer to the parent directory does not help. Using UNC paths and similar hacks does not help, as the installer truncates '\\' to '\'. Tried with CVS from yesterday and about a week ago. Tried nuking ~/.wine and recreating it, that didn't help either. Now that I think about it, there's one more thing I could try: Replacing \ with / - I'll give that a shot when I get near a Wine box again. If you get it working, let me know, I'll be happy to tweak the docs again.
Re: Release plans
Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit : I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries. Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users. Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool. Bye, signature.asc Description: This is a digitally signed message part
Re: Release plans
I wrote: I wrote: Maybe there are much better solutions out there, which could also spare you some precious time having to do those Bugzilla reports you are currently making... See for instance Trac, which has built-in reports, and where the user can in a very simple way create h(is/er) own reports: http://projects.edgewall.com/trac/report Hoop-ti-doo, they even have a bugzilla-2-trac conversion script! http://projects.edgewall.com/trac/wiki/TracImport Flyspray - http://flyspray.rocks.cc/ - is also really sweet. Doesn't come with a bugzilla conversion script, though. Mooch off TSVN's bugtracker if you want to see it live :-). http://tortoisesvn.berlios.de/issues/
Re: Release plans
Jonathan Ernst schreef: Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit : I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries. Well, obviously, the ebuild + source tarball *is* my binary, as it were. It's not like I can effectively use SuSE or FC 4 rpms. So we 'crazy' source-based distro users can go jump, huh? Thanks :) . Funny, I'd call some of the 'pure' users on Wine-Users a lot crazier than I am, given some of the ways they try to use Wine Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. Well that was actually my ultimate question, since I'm working on docs-- if this was in fact a step I needed to find a way to perform, I would document it. But for that I'd have to know what to do, which required knowing the nature of the problem, which I didn't. WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users. OK, thanks for the pointer-- my main problem was knowing if the issue was the ebuild or the actual compilation process. bugzilla.gentoo.org (b.g.o.) I can handle. And thanks for the confirmation that everything ought to work normally (which I would have expected, despite the warning)-- but given our past and current issues with binary compilation, and given that we were specifically asked to check for anomalies in binary installation, I just wanted to be sure. Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool. It really depends on your usage needs as to whether compiling everything from scratch is crazy or not. Clearly a 500-seat or more enterprise workstation farm does not have the time or energy most of the time, but I do. And it gives me a nice sandbox to learn in, since Portage does generally work very well, and since I can see what it did, I can begin to 'understand everything that the compilation process entails'. But OK, enough chitchat, I'm off to post a bug for this-- I'll post the bug number here in case anyone wants to follow it. Thanks for the help, I'm looking forward to taking 20050930 for a spin. Holly P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow Unverified Signature warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask. Holly
Re: Release plans
Le lundi 03 octobre 2005 à 12:19 +0200, Holly Bostick a écrit : [...] P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow Unverified Signature warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask. I sent them to keyserver.net; hope it works signature.asc Description: This is a digitally signed message part
Re: Release plans
On 10/3/05, Molle Bestefich [EMAIL PROTECTED] wrote: What sort of errors do you get? The installer can't create it's installation directory. Creating the directory manually does not help. For now you have to use native comctl32 to install some apps. -- James Hawkins
Re: Release plans
On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) -Brian
Re: Release plans
Le lundi 03 octobre 2005 à 10:13 -0600, Brian Vincent a écrit : On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. Yes everything is ok and Gentoo keeps bringing new releases of Wine much faster than any other distro I know of. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) Agreed. signature.asc Description: This is a digitally signed message part
Re: Release plans
Brian Vincent schreef: On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) -Brian As far as I know, Gentoo (along with many other distros) cleaned up their act w.r.t wine several months ago (when Mike Hearn, I believe, got the various maintainers to *pay attention* to Wine development, rather than just assuming that everything built the same as it had previously month after month-- when it couldn't because so many changes were going on). So Wine has been working fine for me for some time (or rather, it's been working so fine as possible, without any issues I would specifically attribute to the distribution build process). In any case, the bug on b.g.o. can be found here: http://bugs.gentoo.org/show_bug.cgi?id=107971 If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process. Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so Holly
Re: Release plans
Brian Vincent wrote: Anyway, the filename here has demo in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-10361515.html?tag=lst-0-1 No-go, that version expires in 1998. There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/. Same goes for IDA Pro 4.3 freebie edition. If that isn't it, maybe one of these will work: http://www.themel.com/idafree.zip Seems to run, but after that it just hangs. Anyone? From the IDA Pro page about why they don't host it: The distribution of our freeware version was using insane amounts of bandwdith, several hundreds of them are delivered each day. Thanks! http://www.winehq.com/?issue=291#Docs%20Needed Thanks! Francois Gouget wrote: WineHQ's CVS page should be updated with instructions on how to get the documentation: http://www.winehq.com/site/cvs Thanks! Where we're at now: * None of the IDA versions actually both install and work under Wine. * WDASM installs but, ehrr, it looks .. wrong. * GoVest looks good, except that it cries about MapDebugInformation and SymInitialize being stubs. * Also, the documentation is horribly outdated and plain wrong in some places. I've updated the docs to reflect the current state of affairs. Patch forthcoming.
Re: Release plans
Alexandre Julliard schreef: Folks, I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg. Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong. I'm a Gentoo user, and when I installed the package, I received the following rather alarming message at the end of the output (end of compile and beginning of merge included so you can see where it falls, but you'll easily be able to identify the message I'm talking about): make[2]: Leaving directory `/var/tmp/portage/wine-20050930/work/wine-20050930/tools/wrc' ../tools/mkinstalldirs -m 755 /var/tmp/portage/wine-20050930/image//usr/bin /var/tmp/portage/wine-20050930/image//us r/share/man/man1 /bin/install -c ./winemaker /var/tmp/portage/wine-20050930/image//usr/bin/winemaker /bin/install -c -m 644 ./winemaker.man /var/tmp/portage/wine-20050930/image//usr/share/man/man1/winemaker.1 make[1]: Leaving directory `/var/tmp/portage/wine-20050930/work/wine-20050930/tools' ./tools/mkinstalldirs -m 755 /var/tmp/portage/wine-20050930/image//usr/share/aclocal mkdir -m 755 -p -- /var/tmp/portage/wine-20050930/image//usr/share/aclocal /bin/install -c -m 644 ./aclocal.m4 /var/tmp/portage/wine-20050930/image//usr/share/aclocal/wine.m4 /bin/true * * The installed Wine libraries will not be found! You can either: Add the line '/var/tmp/portage/wine-20050930/image//usr/lib' to /etc/ld.so.conf and run /sbin/ldconfig export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/var/tmp/portage/wine-20050930/image//usr/lib * * man: fixing man page symlink: wineg++.1.gz removing old symlink: wineg++.1 gzipping man page: winedbg.1 gzipping man page: winegcc.1 gzipping man page: wmc.1 gzipping man page: wrc.1 gzipping man page: winebuild.1 gzipping man page: winemaker.1 gzipping man page: widl.1 gzipping man page: wine.1 gzipping man page: wineserver.1 gzipping man page: winedump.1 prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded strip: i686-pc-linux-gnu-strip --strip-unneeded usr/bin/wmc usr/bin/wrc usr/bin/widl usr/bin/wine usr/bin/wineserver usr/bin/winebuild usr/bin/wine-pthread usr/bin/wine-kthread usr/bin/winedump usr/bin/winegcc usr/bin/wine-preloader usr/lib/wine/mapi32.dll.so There are a number of problems with this instruction: 1) Many users won't see it, since many users prefer not to watch their output (certainly not for long compiles like Wine), and if they don't have a long scrollback buffer like I do, the only thing they will see is that the emerge completed successfully (so they will not do this step, with unknown consequences); 2) This message is not an einfo (thus not present in the ebuild, it is, of course in the emerge.log file for this emerge); it appears to be generated by the compile process itself, so I'm unsure if it's an ebuild problem or a global compilation problem. Further, I have no indication whatsoever whether the Portage performed this operation on my behalf or not; 3) The directory /var/tmp/portage/wine-20050930 does not exist on my system (which is abnormal in and of itself, as directories from all other Wine emerges do exist in /var/tmp/portage, as do directories for all other applications I've emerged), and even if it did, if the emerge completed successfully, there should be no files remaining in /var/tmp/portage/whatever, since a successful emerge leaves only a /temp directory containing a .keep file and a eclass-debug.log file (at least that's what's left in all the other /var/tmp/portage/wine-version directories I do have on my system). So I cannot even follow this instruction after the emerge is completed (which would be my first opportunity to do so), as the files I'm supposed to update my environment with no longer exist at the location I'm asked to use. I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. I don't know if this is a flaw in the Gentoo emerge process, or the Wine compilation, or even if it's a problem at all (maybe the environment has been updated properly, but I got this message anyway, in error). And if it needs to be fixed (i.e., if I do need to add information to /etc/ld.so.conf), I don't know what to add. At this point, I've got Wine installed, but haven't even tried firstrun, as I don't know if my install is good or not, or whether I might cause even more obfuscation by running
Re: Release plans
Where we're at now: * None of the IDA versions actually both install and work under Wine. You can buy it. It then comes with a Linux console version. Its however pretty high priced. The Windows GUI version of IDA works fine, the Win32 console version too. Don't remember the install anymore ;) Ciao, Marcus
Re: Release plans
Marcus Meissner wrote: Where we're at now: * None of the IDA versions actually both install and work under Wine. You can buy it. It then comes with a Linux console version. Its however pretty high priced. Hehe. Guess that's not an option, then. The Windows GUI version of IDA works fine, the Win32 console version too. Don't remember the install anymore ;) The broken installer is a show-stopper, as far as a debugging guide goes. We can't very well tell people reading the guide that they should install IDA when that in fact is impossible. For now, I've referenced GoVest at the top of the page (although the IDA references are still there). If IDA starts working again, I'd be happy to update the documentation to reflect this. Other options? Maybe mention in the guide how to manually extract the IDA executables from the installer? Anybody knows how this can be accomplished?
Re: Release plans
I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries. Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... -Brian
Re: Release plans
On Sun, 2005-10-02 at 20:18 +, Molle Bestefich wrote: Brian Vincent wrote: Anyway, the filename here has demo in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-10361515.html?tag=lst-0-1 No-go, that version expires in 1998. There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/. That's odd...I got IDA 4.8 demo to install and work without any problems at all. Perhaps something broke recently? What sort of errors do you get? James
Re: Release plans
On Sunday 02 October 2005 5:45 pm, Brian Vincent wrote: Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. IMO the ebuild sounds slightly broken WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... portage builds/installs the package in a sandbox located in /var/tmp/portage, once the build is successful it copies the files to the appropriate locations and records which files it copied where
Re: Release plans
On Sat, 2005-10-01 at 20:12 +0200, Francois Gouget wrote: Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too). It's just simpler this way, we can easily add committers, etc. We can add some info on the CVS page about it though, that should help, right now we don't have anything about it up on the site. No wonder people are confused. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Release plans
On Fri, 2005-09-30 at 15:11 -0600, Tony Lambregts wrote: I have a question though what should I call this release in bugzilla? 20050930 20050930 pre beta 0.9.0 0.9.0 pre beta (20050930) other suggestions Keep it in synch with the real release. 20050930 should do just fine. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Release plans
Dan Kegel wrote: Anyway, I'm trying hard to come up with a web page that makes it easy for even non-wine-developers to help triage bug reports. It's changed a fair bit since I first announced it; if any of you has time to review it, I'd love to hear your feedback. Hello Dan, I've just chosen a bug that I'm triaging now. It's *damn* hard :-). You asked for feedback from non-wine-developers, so here's my 2 cents. 1.) Your web page is a little hard to read. Not sure why, maybe it's just that it's 5-guides-in-1 along with code samples that makes it hard to get a proper overview. 2.) The bugzilla engine that you refer to is hard to use. Which is also witnessed in your page - you seem to do too much explaining (also on referenced pages) about how to actually perform a search in the Bugzilla. It doesn't make your guides easier to follow that the tools I have to learn on the way are (IMHO!) a bit horrible :-/. Try: http://bugs.winehq.com/query.cgi Search for NEW+UNCONFIRMED (default) and Trillian. Bugs 620 and 621 is found. Consider: http://bugs.winehq.org/show_bug.cgi?id=2658 which both contains the word Trillian and has status NEW. Why's it not found? Yaa!... I've spent an hour staring at the search page before it struck me: I have to put the string Trillian in the Comments field. That's just horrid for newbies. Another thing that would help the newbie experience is to, per default, change the STATUS field to contain all color and flavors. That said, it seems that Bugzilla maybe just in general has a horrible interface. Maybe there are much better solutions out there, which could also spare you some precious time having to do those Bugzilla reports you are currently making... See for instance Trac, which has built-in reports, and where the user can in a very simple way create h(is/er) own reports: http://projects.edgewall.com/trac/report (click Custom Query to try that out). Or do a simple search, cleanly separated from the reporting function: http://projects.edgewall.com/trac/search Trac also sports an integrated Wiki where bugs and source code can be cross-referenced. (In Wine's case, Trac would have to point to Troy's SVN repo, since Wine uses CVS.) Example of what that's good for: http://projects.edgewall.com/trac/timeline The above bears resemblence to the 'modified in last 14 days' thingy that you also do, at least if you tick only the 'Tickets' checkbox. Well, just a suggestion :-) Have several nice days /me
Re: Release plans
I wrote: Maybe there are much better solutions out there, which could also spare you some precious time having to do those Bugzilla reports you are currently making... See for instance Trac, which has built-in reports, and where the user can in a very simple way create h(is/er) own reports: http://projects.edgewall.com/trac/report Hoop-ti-doo, they even have a bugzilla-2-trac conversion script! http://projects.edgewall.com/trac/wiki/TracImport
Re: Release plans
Alexandre Julliard wrote: We also still need many documentation updates, so please consider helping with that. I'd like to help wherever I can. Developer docs ok? For instance, in: http://www.winehq.com/site/docs/wine-devel/wine-debugger the IDA debugger is hyperlinked several times. I've searched Google for ever so long, and that file just isn't anywhere around anymore. If it's legal and anyone has a copy, it could be stuffed on the WineHQ web site. (I'm serious - it's nowhere to be found!) Otherwise the documentation should just be updated to mention some other debugger, GoVest for instance. Question is, how do I convey updates to the documentation to you guys? Running 'diff' is not hard, but Where can I find the source for the documentation? It's not in the SVN repo I'm pulling off Troy's server, it seems.. I assume you store it in a CVS repository next to the source code repo? Where do I find it? Apologies for being so noob :-p..
Re: Release plans
On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Question is, how do I convey updates to the documentation to you guys? Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed -Brian
Re: Release plans
On 10/1/05, Brian Vincent [EMAIL PROTECTED] wrote: On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Question is, how do I convey updates to the documentation to you guys? Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed Oops. Thanks! If anyone has the copy of IDA that the current guide mentions, or know whether it is functionally equivalent with some other product, please speak up.
Re: Release plans
On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: If anyone has the copy of IDA that the current guide mentions, or know whether it is functionally equivalent with some other product, please speak up. That's odd.. Anyway, the filename here has demo in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. Uwe would probably know since he seems to use/test it a lot. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-10361515.html?tag=lst-0-1 If that isn't it, maybe one of these will work: http://www.themel.com/idafree.zip http://www.dirfile.com/ida_pro_freeware_version.htm# From the IDA Pro page about why they don't host it: The distribution of our freeware version was using insane amounts of bandwdith, several hundreds of them are delivered each day. Here is for example an Analog report for Dec 2002 and Jan 2003 20013: 93.98%: 27/Jan/03 23:18: /freefiles/freeware.zip One of our hopes in distributing this freeware version had been that it would diminish the number pirate contacts. Unfortunately, this has not been the case. That is why, after having delivered hundreds of thousands of copies of IDA Freeware, we have decided not to host this file anymore. Note that the IDA Pro freeware license doesn't change : the freeware version remains freeware, and anyone willing to host it is welcome to do so. -Brian
Re: Release plans
On Sat, 1 Oct 2005, Brian Vincent wrote: On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Question is, how do I convey updates to the documentation to you guys? Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed WineHQ's CVS page should be updated with instructions on how to get the documentation: http://www.winehq.com/site/cvs Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilisé par les informaticiens en lieu et place d'idiot.
Re: Release plans
On 10/1/05, Molle Bestefich [EMAIL PROTECTED] wrote: Anyway, I'm trying hard to come up with a web page that makes it easy for even non-wine-developers to help triage bug reports. [ http://kegel.com/wine/qa ] You asked for feedback from non-wine-developers, so here's my 2 cents. Great! Thanks for writing! 1.) Your web page is a little hard to read. Not sure why, maybe it's just that it's 5-guides-in-1 along with code samples that makes it hard to get a proper overview. Think it would help to break it up into multiple pages? I'm afraid that would just make it harder to follow. 2.) The bugzilla engine that you refer to is hard to use. I admit it takes some time to get used to, but I don't think switching to something else is an option at the moment. I've spent an hour staring at the search page before it struck me: I have to put the string Trillian in the Comments field. That's just horrid for newbies. True! I updated my page to lead newbies through searching for a particular app's bugs. Have another look at http://kegel.com/wine/qa/#tools and let me know if it's any better now. Another thing that would help the newbie experience is to, per default, change the STATUS field to contain all color and flavors. Agreed. That's worth considering. (Any Bugzilla administrators want to comment?) - Dan
Re: Release plans
I think we need some more clean up of bugzilla, we need to close bugs till 2003/04 which have not updates since 6 months. And also those which cannot be replicatable. bye, Vijay On 9/30/05, Alexandre Julliard [EMAIL PROTECTED] wrote: Folks, I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg. Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong. Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix. We also still need many documentation updates, so please consider helping with that. If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the MMDD format... If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in. Thanks everybody for your help, it has been a long trip but we are getting there... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Release plans
On 9/30/05, Alexandre Julliard [EMAIL PROTECTED] wrote: We also still need many documentation updates, so please consider helping with that. Is anyone actually working on this? I might have some time this weekend, but I don't want to step on any toes. -Brian
Re: Release plans
Brian Vincent schreef: On 9/30/05, Alexandre Julliard [EMAIL PROTECTED] wrote: We also still need many documentation updates, so please consider helping with that. Is anyone actually working on this? I might have some time this weekend, but I don't want to step on any toes. -Brian Yes, actually, but right after I volunteered I caught a really bad cold that took me some time to get over. Today is the first day that I feel healthy enough to think about complex things (but unfortunately my boyfriend caught the bug from me, so I'm not getting back up to speed as fast as I might want). In any case, now that there's a new monthly, I can install it this evening and start doing things like a new user to see what the process currently looks like from that angle and what seems like it might need to be written down. So I'm here/back. Holly
