Retiring winetestbot
Folks, I am writing to announce that we will be retiring the original Wine Test Bot, written by the late Ge van Geldorp, as of August 31, 2013. We will switch over to the new test bot that Francois has been working on at that time. On September 1, we'll panic and fix everything that is broken grin). I want to thank Ge's family, notably his brother Arno, for keeping the servers running these years since Ge passed away. It's also important to note how incredible a contribution the Wine Test Bot has proven to be for the Wine project; Wine owes an incredible debt to Ge, and I hope we can all collectively work to remember the great gift he gave us and the world. Cheers, Jeremy
Another major milestone
Alright folks, I have to confess that the 1.6 release came and I didn't immediately get up and dance. In fact, a new Wine release was almost...boring. I think we have to consider that a major milestone in of itself. New, useful releases are just a matter of course for us now. Woohoo! Now I'm dancing grin. Cheers, Jeremy
Re: winehtml5.drv: Added new HTML5 driver.
On 04/01/2013 07:22 AM, Ken Thomases wrote: On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: There are still some missing features. Most notably, it lacks support for system tray baloons. I know; that's, like, the hardest thing to do! In other news, Alexandre has accepted a job at Microsoft. He has relinquished the maintainer role to me in his place. I've gone ahead and committed this and removed both the Mac driver and X11 driver as well. Cheers, Jeremy p.s. I expect all future commits to have a comment to code ratio of at least 10:1; they will be automatically rejected without that change.
FOSDEM logistics
Hi folks, Alright, this is it - we're going to try to get together at FOSDEM starting this Friday. If you are planning on being there, you should make sure to subscribe to the wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf All further logistics emails and discussions will take place there. So if you're not subscribed, you can't complain we didn't try to include you in the planning. We plan on informally assembling in the lobby / bar of the Best Western Hotel Royal Centre (http://www.royalcentre.be/) on Friday, most likely starting in late afternoon. I don't have any plans for Saturday; I'll likely go harangue the Xorg guys, and maybe catch the key note. We may try to informally gather as well. However, there is no plan for Saturday dinner (sorry, no sponsored dinner by CodeWeavers this year). I have no idea how FOSDEM usually works on Saturday night, so I figured we'd just play it be year. Advice is welcome. Our devroom starts Sunday at 9:00 am. We're in building K, which you can see on this map: http://www.ulb.ac.be/campus/solbosch/plan-K.html Main FOSDEM entrance / registration is in building H on that map. One bit of unsolicited advice - when I naively copy/paste the address on the FOSDEM page into Google maps for directions, I end up with the wrong location. If you're at the Best Western, it looks like Tram 94 goes to the Legrand stop in 16 minutes, and then a 10 minute walk carries you the rest of the way there. Looking forward to seeing you all on Friday! Cheers, Jeremy
Re: wiki
Our server is up, but it looks like the winehq DNS has a problem: Hmm. I'm not seeing that; if I use dig on all 3 of the winehq.org DNS servers, I get the appropriate record, and a dig against 4.4.4.4 and 8.8.8.8 get the cname as well... Cheers, Jeremy
Re: Mail problems for wine-patches
I also unsubscribed and subscribed again to the wine-patches list. Any ideas? Has wine-patches a whitelist? We use an exim rule to screen out IP addresses flagged in the SORBS database. Unfortunately, the outbound mailer for your domain is listed; here is the exim error report: 212.227.17.11 is listed at dnsbl.sorbs.net (127.0.0.6: Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?212.227.17.11) I have temporarily added *.web.de to the whitelist which should, in theory, allow these emails through. I'll allow Jeremy Newman to comment on what he thinks would be a better long term solution. (It looks like it's touch and go, because you go this email through somehow :-/). Cheers, Jeremy
Re: Call for papers - FOSDEM 2013
On 11/01/2012 01:59 PM, Jeremy White wrote: Alright folks, We need to put together a schedule for our room at FOSDEM. So I would like to formally 'call for papers' for FOSDEM. Please email suggested topics to winec...@winehq.org, where I'll collate them and piece them into a schedule. A 'paper' can be a talk you wish to give, or a topic you think we should discuss. As always, they should be relatively brief, and should emphasize discussion and collaboration. This year it probably makes sense to imagine a few talks aimed at developers outside the Wine community. After all, the hope is that a few bored non Wine developers may wander by from time to time. Perhaps we can suck them in grin. Reviewing what 'other' FOSDEM devroom guys have done, I see that I failed to establish a deadline for the CFP. So let me hereby arbitrarily pick December 31, 2012. Please get your proposals in no later than then; we'll then cull through the suggestions and set the agenda. I will likely add a section for breakouts or general discussion as well. Cheers, Jeremy
Re: We're in at FOSDEM!
Hey Jerome, On 12/12/2012 07:04 PM, Jerome Leclanche wrote: Has there been any further decision about this? I'll be at FOSDEM on behalf of Razor and would love to sit in at the Wine talks. I'm not entirely sure what you're asking. We will definitely be at FOSDEM and will have a DevRoom on Sunday. We don't (yet) have a hotel, nor do we have a full agenda. But we're not alone, I gather it's typical of most projects to scramble at the last minute. At the moment, I'm considering booking the Best Western Royale Centre: http://www.royalcentre.be/ It has the right combination of moderate price and a hotel bar :-/. It's really hard to judge location; it's a 30 minute tram ride away from the conference, but it seems as though most hotels are going to be a fairly ways away. Of course, everyone is welcome to make their own decisions, but it seems like it would be more fun if we all stay together. Again, if anyone has any opinion on this, or first hand knowledge of Brussels, that would be welcome. Cheers, Jeremy p.s. Please follow up on the wineconf list.
Sponsorship to FOSDEM's Wine room
The Wine project has a limited fund to sponsor travel to the Wine conference. If you are interested in attending the Wine DevRoom at FOSDEM, but could only do so with financial assistance, we may be able to help! To apply, simply email me a request and indicate if you need help with transportation costs, lodging costs, or both. If you need help with transportation costs, please provide an estimate of your travel costs. Funding decisions will be made by a five member committee including myself, Alexandre, Michael Stefaniuc, Austin English, and Marcus Meissner. Priority will be given to those that have contributed to the Wine project in some form (not necessarily patches). Please send your request to me no later than December 31, 2012. We will try to communicate decisions on or before January 5th, 2013. Cheers, Jeremy
Re: We're in at FOSDEM!
We should stay in the same hotel if possible to ease gathering. Did someone already choose one? Could You make a special arrangement again (like in Paris, IIRC)? No, we haven't yet picked a hotel. I was poking around a bit; looks like it's not obvious. I see that other projects have varying strategies for handling this. Anyone feeling like a travel planner and want to volunteer for that job? Or anyone know Brussels and/or FOSDEM such that they can suggest good strategies? Cheers, Jeremy
Re: Call for papers - FOSDEM 2013
WineTestBot is after all Wine-specific. Also I feel like all I have about the really interesting subjects(*) is questions which does not really make for a good presentation. But at the same time I'd be interested in ideas from others and the FOSDEM people may have faced some of these issues already, or at least set up sophisticated automated testing systems and know what works and what doesn't. It's okay for us to have talks that are Wine specific. We get *our* room for a day for *our* nefarious purposes. I was just encouraging us all to have an eye to possibly luring in a few others as well; we shouldn't forego positive and useful conversations in the hope that we'll engage others. So could you please submit that formally to winec...@winehq.org? Cheers, Jeremy
Re: Call for papers - FOSDEM 2013
So I would like to formally 'call for papers' for FOSDEM. Please email suggested topics to winec...@winehq.org, where I'll collate ^^^ I propose a talk about the status of 3D rendering support for games on Linux. I don't intend to make this highly Wine-specific, and instead include the state of Mesa, fglrx, nvidia and OSX graphics drivers. Favor - formally submit this to the Wineconf list? Thanks, Jeremy
Call for papers - FOSDEM 2013
Alright folks, We need to put together a schedule for our room at FOSDEM. So I would like to formally 'call for papers' for FOSDEM. Please email suggested topics to winec...@winehq.org, where I'll collate them and piece them into a schedule. A 'paper' can be a talk you wish to give, or a topic you think we should discuss. As always, they should be relatively brief, and should emphasize discussion and collaboration. This year it probably makes sense to imagine a few talks aimed at developers outside the Wine community. After all, the hope is that a few bored non Wine developers may wander by from time to time. Perhaps we can suck them in grin. Cheers, Jeremy
We're in at FOSDEM!
I'm stoked - we've been approved for a dev room at FOSDEM on Saturday, February 2nd, in Brussels. It is just the one day, but I figure we can find ways to gather on Friday night and/or Sunday as well. I really think this will be a fun change of pace for us. If it doesn't work out, we'll just go camp out in Marcus's back yard instead evil grin. One thing they require from us is a pre set schedule, so I'll be asking people to suggest topics, and then we'll have to weed through them to figure out what makes the most sense. Cheers, Jeremy
Re: Wine release 1.4
On 3/7/12 10:21 AM, Alexandre Julliard wrote: The Wine team is proud to announce that the stable release Wine 1.4 is now available. Let me be the first to say: Woohoo Cheers, Jeremy
Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
Hi Folks, It's that time of year again - summer of code is going to start up soon. Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process? Cheers, Jeremy --- Conservancy Projects, I want to draw your attention to the fact that Google's Summer of Code program for 2012 is now accepting applications. Carol Smith wrote at 11:43 (EST) on Saturday: We're pleased to announce that Google Summer of Code will be happening for its eighth year this year: [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 In particular, take a look at [3], which has the calendar for the SoC 2012 program.
Re: Wine automated testing update
On 02/03/2012 10:47 AM, Dan Kegel wrote: Jeremy wrote: the VMWare folks are not willing to provide a permanent license for VMWare to us. So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate. What's the plan for automated MacOSX testing? I hear 10.7 supports running in a VM... No plan at all, which is an oversight. I think we may have to have a 'real' Windows box to do any kind of credible D3D tests; perhaps we have to make the same argument for Mac OSX. But boy it sure would be nice if we could put MacOSX into a VM... Cheers, Jeremy
Wine automated testing update
Hi Folks, At the last Wine conference, I volunteered to find a home for the WineTestBot that Ge's brother has been hosting, and to take over the Buildbot that Dan and Austin have been so diligently maintaining. This is an update on that project, mostly to help keep my procrastinating self moving it along. First, we have a lovely set of hardware; 4 servers, in a dedicated rack, with a dedicated static ip to the outside world. One server is the gateway, 2 are dedicated Linux test systems (with nice fast processor + gpus), and one is a beefy system capable of running many VMs. The plan was to move the existing VMWare based WineTestBot to this hardware and simply get the existing system up and running on the new hardware. Here we hit our first snag; the VMWare folks are not willing to provide a permanent license for VMWare to us. So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate. I've done a little of this work, and Maarten is hopefully going to help me try converting the existing VMs to see if we can save any hassle by doing a conversion. In parallel, I learned a great deal about buildbot and the buildbot system that Dan has built. There are two especially valuable and useful functions provided by this buildbot: the first is essentially a patch watcher; a process that catches simple mistakes (e.g. build errors on different architectures, and so on). The second is more powerful and is encapsulated by the 'dotests.sh' shell script. The dotests.sh script does a good job of basically running make test and noticing any test failures outside of 'the usual ones'. There is an infrastructure for Buildbot is a good tool, and I invested a lot of energy into it (as have Dan and Austin). However, Alexandre has persuaded me that we should first explore integrating the dotest.sh functionality into the existing WineTestBot, as that would allow us to have a very simple clean web page, and would also allow us to integrate most cleanly with Alexandre's back end tools. Of course, WineTestBot is Perl code, and my Perl fu is low. So I have recently asked Francois to help with that effort as well. So the basic plan is as follows: 1. Test qemu/kvm with a few Windows versions to see if it'll work. 2. If so, modify WineTestBot to use qemu instead of vmware. (This is 'easy' because the WineTestBot code nicely isolates the VM functions, but 'hard', because VMWare provides some APIs that may have to be replicated). 3. Migrate WineTestBot to the new hardware stack 4. Write new code to run 'dotests.sh' as part of WineTestBot Cheers, Jeremy
Re: Rethinking WineConf
Thank you for all the replies. Here is what I've taken away so far: 1. Our intro text was overtly hostile to users. I've removed that. 2. Potential attendees want a clear agenda. 3. Coordinating with another event remains interesting. So, exploring #3 a bit further - what if we asked for our own track within FOSDEM 2013? (I presume that would be February 2013 in Brussels) It would let us all get together, allow us to have a few sessions targeted at non Wine developers, and could also save us some hassle. And I like Belgian beer. Would we lose some of the joy of having our very own conference? We could try it once and go back to the old format if it doesn't work out. Of course, given our (so far) non participation in FOSDEM 2012, we may not be welcome... :-/ Cheers, Jeremy
Re: Rethinking WineConf
Posted: Tue Jan 10, 2012 6:07 amPost subject: If you really want users to come, I suggest you change the second sentence on http://wiki.winehq.org/WineConf. Right now it sends a very clear message that users are not the least bit welcome. /me winces. I wrote that text; and I never intended it to make anyone feel unwelcome. The thinking when I wrote it was to give fair warning that the topics would be primarily developer oriented. I've amended that text. So then let's imagine that users now feel welcome, and they come in droves. Aside from going to the pub, what would make for a good conference? Cheers, Jeremy
Rethinking WineConf
Hi All, This past Wine conference, while great fun as always, was not as well attended as Wine conferences in the past. So I would like to stir up trouble by suggesting we rethink WineConf. For those that have not attended, the Wine conference has been a mostly annual affair since 2002. It is open to all, but is advertised as being aimed at Wine developers. About 35 people attend each year. It's been in Minnesota about every 3rd year, and is otherwise 'normally' somewhere in Europe. I see the primary goal as creating human bonds between otherwise anonymous people (aka going to the pub). It's a bonus if it also spurs resolution to tricky issues, or motivates people to get more done. So I'd like to ask folks to brain storm with me. How could Wineconf be different? If you've never been, what would encourage you to come? If you've been to a technical conference recently that you thought was well done, what did they do well? Anything we could emulate? Any other ideas, or suggestions? Cheers, Jeremy
WineHQ database compromise
Hi, I am sad to say that there was a compromise of the WineHQ database system. What we know at this point that someone was able to obtain unauthorized access to the phpmyadmin utility. We do not exactly how they obtained access; it was either by compromising an admins credentials, or by exploiting an unpatched vulnerability in phpmyadmin. We had reluctantly provided access to phpmyadmin to the appdb developers (it is a very handy tool, and something they very much wanted). But it is a prime target for hackers, and apparently our best efforts at obscuring it and patching it were not sufficient. So we have removed all access to phpmyadmin from the outside world. We do not believe the attackers obtained any other form of access to the system. On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked. This, I'm afraid, is a serious threat; it means that anyone who uses the same email / password on other systems is now vulnerable to a malicious attacker using that information to access their account. We are going to be resetting every password and sending a private email to every affected user. This is again another reminder to never use a common username / password pair. This web site provides further advice as well: http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-for-internet-web-sites/ I am very sad to have to report this. We have so many challenges in our world today that this is a particularly painful form of salt for our wounds. However, I think it is urgent for everyone to know what happened. Cheers, Jeremy
Re: WineHQ database compromise
Almost 2 years ago I have sent you an email privately about a security hole with the database. To be exactly, the date of the email is Wed, Jul 29, 2009, 12:00 AM (GMT +02:00). I guess that's probably the same trick the bad guys have used... Hmm. I can't find any such email in my archives - can you resend it to me? Are you sure it was me, and not the other Jeremy? I'd be curious to see if it matches up to the forensics we have. Cheers, Jeremy
Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
Hi Folks, I try to send out a periodic message to the wine-devel mailing list outlining the 'corporate' structure of Wine and how some decisions are made. We work with the Software Freedom Conservancy. They manage the pieces of Wine that benefit from a formal organization, such as managing money, holding Trademarks, and so on. The primary activity we have conducted with them over the past several years is managing money - about $3,000 each year. They manage all funds donated to Wine - the donate button goes into a bank account they manage and any larger private donations go there as well. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, we have a decision group and we require a majority of members to approve any spending. Alexandre and I are the current members of that group. We also claim the right to appoint anyone else to replace or augment the decision group. We CC all decisions to an auditor. We have recently asked Michael Stefanuic to replace Zachary Goldberg in that role. A critical requirement, we feel, is that a non CodeWeavers staff member be fully aware of all decisions made. We choose this strategy rather than a fully public process so that we can apply discretion and protect privacy of people that ask for help with travel funding. The SFC will recognize a 'revolt' by the Wine project. That is, the designated decision group can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has primarily been to help defray travel costs for Wine contributors to come to Wineconf. Wine's income has been around $3,000 / year for the past few years; we tend to spend down much of the balance each year for Wineconf. Cheers, Jeremy p.s. One note - the SFC also manages the GSOC payments, although I believe that they ostensibly manage that on behalf of Google, not really Wine. That is generally coordinated by Wine's GSOC coordinator, and Alexandre and I have nothing to do with it.
Alexandre's keynote
Thanks to Jon Parshall's hard work, we have Alexandre's keynote available here: http://www.youtube.com/watch?v=2rdDvMonTnQ Remember to have your libation at hand so you can play the game... grin Cheers, Jeremy
Re: gsoc mentor summit
fyi, Bradley writes the following missive, which I am just relaying: --- TL;DR Version: *Now* is the time for all your org-admins to be in touch with Conservancy. Please make sure that org-admins (a) read everything below, (b) get in touch with me right away, and (c) talk to me directly before doing things regarding POs and other funds with Google. Full Version: This year, there are seven Conservancy projects in the SoC: Boost Evergreen Git Inkscape Samba Selenium Wine I hope you all have had an excellent summer mentoring your students and all has gone well. Upon the seen ding of Carol's email that I quoted in part below, we've reached the moment in the SoC process where Conservancy gets involved. Namely, when invoices to Google need to happen RSN. I don't actually have on file the email addresses of all your org-admins in the SoC this year. So, this email may not be relevant to everyone receiving it. However, if you could email me back each and tell me who your org-admin is, I'd much appreciate it, and I'll redirect this email to that person. I want to make you aware of three important things: (a) If some of you are going to the Mentor Summit, and are having trouble prepaying for your flights due to lack of personal funds: Carol Smith wrote on the 25th of July: All orgs pay for plane tickets ahead of time and then request reimbursement via invoice against the PO once you have receipts for the flights. Then let me know and I'll see if Conservancy can help by prepaying for you, pending the reimbursement from Google. (b) I should have emailed you sooner, but I want to remind you that we'll do an omnibus PO with Google for all mentor payments and all travel reimbursements. I'd appreciate if the org-admins could get in touch with me right away so we can begin coordinating this. Please keep me in the loop on anything you do with regard to PO details with Google and the like. I'm also in touch with Carol Smith at Google in parallel to this thread, to make sure we're all coordinated. In particular, get me travel receipts as early as possible for all those going to the Mentor Summit. (c) Oh, and I *really* encourage you all to take advantage of the mentor summit invitation. Flight/hotel is funded by Google, and it'll be a great chance for us to meet up as Conservancy projects. I'll be there as well, so I look forward to seeing you there! -- Bradley M. Kuhn, Executive Director, Software Freedom Conservancy --- Cheers, Jeremy
Summer is ending, you can't procrastinate any more, come to Wineconf!
So summer holidays are rapidly ending, and before you know it, Wineconf will be upon us - just 5 more weeks until Wineconf! The full details, including the hotel information, is available here: http://wiki.winehq.org/WineConf2011 For those of you that have asked for sponsorship, I'm trying to come to a 'final' set of requests so I can figure out how best to divvy up the funds we have available. I hope to have that info soon. If you're interested in coming, but can't afford it, please write to me privately to see if we can help. Hope to see you there! Cheers, Jeremy p.s. I promise to try to keep most discussion on the http://www.winehq.org/mailman/listinfo/wineconf mailing list, which you should join now if you're at all interested in Wineconf.
WineConf 2011 - Minneapolis, MN - October 1,2
Hi Folks, We have made arrangements for this year's WineConf to happen in Minneapolis, MN on Saturday October 1 and Sunday October 2. Minneapolis is the little known other city of the Twin Cities across the river from our home town, St. Paul. I've put some preliminary information up on the Wiki: http://wiki.winehq.org/WineConf2011 We thought that this year it would be fun to stay in downtown Minneapolis, as there is quite a bit to do there. Further, at that time of year, the weather has a good chance of being beautiful, so it will hopefully be a great time for all. I checked, and only very rarely has it been below freezing on October 1 evil grin. (Seriously, it's usually very nice. Really. Trust me). If you are interested in WineConf, and have contributed to Wine, but are not sure if you can afford the travel costs, please write to me. The Wine Party fund is used mostly to defray travel costs these days and we may be able to help. Note that most further communication will happen on the winec...@winehq.org mailing list; if you're interested, you should subscribe. If you're coming, please hit the RSVP page: http://www.winehq.org/wineconf/rsvp/ Hope to see you in Minneapolis! Cheers, Jeremy
Volunteer needed - a Lurker would be perfect!
Hi Folks, Throughout the years, Wine has been lucky to have a procession of great volunteers who work on areas outside the code. And right now, we find ourselves in need of a new Wine Weekly News editor. Zachary Goldberg, our current editor, has really not been able to find the time to keep up and would appreciate it if someone else was willing to volunteer. What we need is someone who is willing to read wine-devel, and perhaps scan wine-users, and put together a periodic high level description of activity within Wine. It probably wouldn't have to be weekly; monthly would be just fine. The only requirements are enough technical background that you can make some sense of the mailing list information, some modest skills with the written word, and the willingness to help. In exchange, you'll earn fame, fortune (well, okay, maybe a free beverage once a year), and the deep satisfaction of being a critical voice for the Wine project. If you're interested, email me privately. Cheers, Jeremy
Re: [website 1/2] Add a Donation Page with more Options
Hi André, Several thoughts. I'm not aware of any source of revenue that comes to us via Amazon or CDNow. We might want to remove that. I'm also a bit concerned about the T-shirts; we should get a report on that, I don't know that we've gotten much. Also, we should track this; after we change, we should see how much donations are, and then see if we think it's better or worse than what it was before. It's hard, as donations are quite variable in timing and amount. Cheers, Jeremy
Google Summer of Code Mentors?
Did we have an 'official' leader for GSOC this past year? If not, could I ask someone (*cough* Kai *cough*) to nominate themselves? We need to coordinate getting some information to the SFC so that we can collect the mentor stipend from Google. Cheers, Jeremy
Mentor summit for Google Summer of Code - time sensitive
As a heads up, Bradley reminds me that the Mentor summit for GSOC: http://gsoc-wiki.osuosl.org/index.php/2010 is coming up; the registration deadline is tomorrow. Google may reimburse travel expenses, so if cost is an issue, we may be able to help with that. If you need such help, let me know, and I'll connect you with Bradley. Cheers, Jeremy
Wineconf 2010: You're running out of procrastination time...act now! Supplies are limited!
Alright, we're now down to about six weeks out. Soon, flights and the rooms will go up in price. So book your travel now! One new favor - if you are coming, please RSVP here: http://www.winehq.org/wineconf/rsvp/ so we can have counts for meals and such. Again, if money is an issue, please write to me; the Wine Party Fund may be able to help. And, as always, the Wiki page has the latest scoop: http://wiki.winehq.org/WineConf2010 and most chatter is happening on the winec...@winehq.org mailing list (except for pushy loud mouthed types like myself :-/). Cheers, Jeremy
Re: DIB clarification
This could also help. If I recall correctly, Jeremy White mentioned at Wineconf 2008 that this was a major reason they haven't invested serious energy into one themselves: they had a hard time finding an application that they cared about that benefited significantly from a DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't care about AutoCAD, or whether they hadn't tested with it, or whether my memory is just faulty, I'm not sure. Yes, that's essentially right, although note that we did invest some fairly serious energy into the DIB engine prior to coming to that conclusion. (I remember how pleased Huw was that his benchmarks were 1000 times faster, and how displeased he was when it made Powerpoint slower...) That effort all went into Wine, and I hope and believe that it has helped others as they have worked on the DIB engine. But we don't have any secret stash of DIB engine code to further our evil plans for world domination. We rely on our gorgeous femme bots and Alexandre's magic 'all' patch for that grin. Cheers, Jeremy
Re: WineConf 2010
Paris is a big city, where is the venue? We're still negotiating. It looks like it will be the Ibis Paris Bastille Opéra, but but don't consider that certain. (And, sadly, I'm developing a bias against Parisian hospitality workers :-( ). Cheers, Jeremy
Apologies for the marketing message
It's not clear how it happened; it was not intended. These are direct emails James sends periodically to customers reaching the end of their support period. We speculate that someone signed up with the mailing list address as 'their' address. At any rate, by way of apology I'd like to remind everyone that all contributors to Wine are entitled to VIP status with CodeWeavers, which gets you free lifetime subscriptions to CrossOver. (This way, there is no chance James could ever sell you anything grin). Write to me if you'd like me to set you up. We are deeply grateful for everyones contributions to Wine, and very sorry for the off topic emails. Cheers, Jeremy
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
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: chromium in wine now works with gmail
Dan Kegel wrote: This message is being sent in gmail in Chromium running on Wine with options --no-sandbox --use-nss-for-ssl. w00t!
Re: Wine FIXME Report 2009 Aug - Dec
The Top Ten Single Charts - This are the messages with the most occurrences in a single file. Nifty! How hard would it be to add some git-blame fu to that, and then we'd know who to blame evil grin? Cheers, Jeremy
Re: [winspool 2/6] Move the dlopen of libcups to a separate function, allowing CUPS to be used prior to the full on loading of CUPS printers.
Hi Detlef, Detlef Riekenberg wrote: Hi Jeremy What is your reason for your work in winspool.drv? What are your plans? I'm just trying to fix printing in Acrobat Reader 9.2 for a client; this test shows the current failure: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/winspool.drv/tests/info.c;hb=13a9c037f4c5bc88be241a66e6dcc374ae39eae0#l2407 Even if the Patchset changes some things, it's not the correct location to do that. winspool.drv must not do anything with the registry or the driver files. winspool.drv must not use cups at all wineps.drv must not use cups at all That all belong to a print provider, together with a print monitor. To make our live easy, the printprovider and printmonitor for CUPS and LPR will be integrated into localspl.dll (windows is using seperate provider/monitor: See inetpp.dll and lprmon.dll with friends) I have a Patch here for moving AddPrinter to localspl, that address most of your changes, but a small peace of code is only in my test app and not in the Patch yet (get default DEVMODEW from the Driver) An important issue is, that we store DEVMODEA in the registry. Code is there to handle that, bu it failed on julliards machine. Right; the more I worked on this, the less I knew grin. And I do still feel that I'm a bit out of my depth here, so I appreciate your advice very much. My hope is that this patch set does not make things worse. I mostly rearrange the handling of cups and registry code within winspool.drv and wineps.drv. My localspl.dll has a cups.c, but that need more work(i can't continue before mid januar). And IMHO, using wine_get_unix_file_name in High-level dlls is wrong by design. Well, I believe you will have to use it where ever you invoke CUPS, so that is really tied to the location of our CUPS code more than anything. W2k pro and XP pro have driver directories only for supported environments. (Servers are different) When you think, that you need the driver directories, they can be created with wine.inf Right; I first tried to change wine.inf. But then I found that the initial system printer loading was invoked prior to the inf file processing (it happens at winspool.drv dll attach time). Perhaps that is wrong and should be fixed. Please avoid ANSI strings in new code. (strdupWtoA should go away) I initially implemented this with wide strings. That led to cover functions WINSPOOL_GetPPDNameA and WINSPOOL_CopyPPDA because the code it interfaces with was ANSI. It struck me as ugly and I imagined Alexandre telling me it was wrong. Alexandre, was that the wrong choice? Candidly, the fundamental issue seems to be whether or not trying to solve this issue should be frozen until you can get your revamp in. Would my patch set make your life substantially harder? I think your change is vital, and I really don't want to do that. My hope is that my patch set would be at worst a minor nuisance, and could thus go in. Cheers, Jeremy
Re: [usrmarshal] Adjust new tests to pass on win9x platforms.
It looks like a good place to use broken(). I don't think it's broken on win98; it looks as though they do 4 byte alignment prior to the data structure in win9x, and winnt and on seem to do 8 byte alignment prior to the data chunk. That results in a 4 byte difference. Cheers, Jeremy
Slackware packager?
So Adam Schreiber reports that he's no longer doing the Slackware packages. Is there an active Packager currently? If so, can you submit a patch to remove Adam's name and insert yours? If not, I guess I'll submit a patch to remove that column for Slackware... Cheers, Jeremy
Re: Introducing WineTestBot
Let me be the first to thank Ge for this awesome piece of work. Seconded! It's really quite slick, for anyone that hasn't used it. It's a very nice way to quickly feel comfortable that the test you just wrote actually works in more places than just your mind. Thanks again! Cheers, Jeremy
My script for doing testing
So I have done my penance for failing to set up
a cron to run testing. I've got routine testing
going every night on 2 boxes. It seems solid.
I see that many others have done this as well - test.winehq.org
wine results are really looking good.
As promised, I'm attaching the script I'm using.
This is my crontab line:
06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git
--tag jw-nv-32
e.g. run the script at 2:06 am Tuesdays through Saturdays.
I don't want this to be a general call for everyone
to run this script; rather, this might be a handy tool for
developers who are already running winetest to
save them a little hassle.
My script probably has only one materially useful
feature - it uses a trap to enforce a timeout.
The rest is all pretty easy/obvious stuff.
Also, I've only tested on Linux, not Mac. Sorry :-(.
Cheers,
Jeremy
#!/bin/bash
#
# winetestcron
# script to run the Wine tests in an unattended fashion
# Intended to be run from cron. If you run it in the
# crontab of the user that is logged in to DISPLAY :0,
# it should work. Otherwise, you might want to do a
# xauth extract /your/file in your .xsession, and an
# xauth merge /your/file in this script.
#
function usage()
{
echo -n $0 --repo /path/to/your/.git/dir
echo [--tag tag-to-report]
echo -n[--gecko gecko-path]
echo [--timeout secs] [--update-repo]
echo[--configure extra-configure-args]
echo repo is mandatory, must give the location of a .git directory, and
echo will not be changed by default. If you specify update-repo, then a
echo git fetch will be done in your repository before running winetest.
echo The working tree will not be changed in any case.
echo tag is the tag name to report; see common tags on test.winehq.org for
guidance.
echo timeout sets an overall script timeout, in seconds. Default is
$TIMEOUT
echo gecko specifies a path to the Gecko CAB file. Default is
$GECKO_LOCATION
echo configure will pass through the options to ./configure
}
function parse_args()
{
GOPT=`getopt -o -l repo:,tag:,gecko:,timeout:,configure:,update-repo --
$@`
GOPTERR=`getopt -o -l repo:,tag:,gecko:,timeout:,configure:,update-repo
-- $@ 21`
eval set -- $GOPT
if [ $? != 0 -o $GOPT != $GOPTERR ] ; then
usage
exit 1
fi
while true ; do
case $1 in
--repo)export REFERENCE_GIT=$2; shift 2;;
--tag) export TAG=$2; shift 2;;
--gecko) export GECKO_LOCATION=$2; shift 2;;
--configure) export CONFIG_EXTRAS=$2; shift 2;;
--update-repo) export UPDATE_REPO=y; shift;;
--)shift; break;;
*) echo Error: uknown option $@; usage ; exit ;;
esac
done
if [ $# -gt 0 ] ; then
echo Error: Unexpected parameters $@
usage
exit 1
fi
if [ ! -d $REFERENCE_GIT ] ; then
echo Error: --repo must point to the .git directory of a valid WineHQ
clone.
usage
exit 1
fi
}
function cleanup
{
$TESTDIR/wine/server/wineserver -k
find /tmp -maxdepth 1 -type d -name 'winetest*' -ctime +2 -exec rm -rf {}
\;
exit
}
#---
# Set defaults
#
export GECKO_LOCATION=/usr/share/wine/gecko/
export TIMEOUT=3600
export TAG=`echo -n \`whoami\`-\`uname -m\` | sed 's/_/-/g'`
#---
# Validate arguments
#
parse_args $@
#---
# Get going...
#
TESTDIR=`mktemp -d /tmp/winetest.`
TMPGITDIR=$TESTDIR/wine
mkdir $TESTDIR/gecko
if [ -f $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab ] ; then
cp $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab $TESTDIR/gecko/
else
echo $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab not found. Bandwidth being
wasted...
( cd $TESTDIR/gecko ; \
wget -o $TESTDIR/wget.log
http://downloads.sourceforge.net/wine/wine_gecko-1.0.0-x86.cab \
)
fi
if [ $UPDATE_REPO = y ] ; then
git --git-dir=$REFERENCE_GIT fetch origin
fi
git clone --reference $REFERENCE_GIT git://source.winehq.org/git/wine.git
$TMPGITDIR $TESTDIR/clone.log 21
cd $TMPGITDIR
(./configure $CONFIG_EXTRAS nice make ) $TESTDIR/build.log 21
export WINEPREFIX=$TESTDIR/.wine
export PATH=$TMPGITDIR:$PATH
export DISPLAY=:0
cd $TESTDIR
# Set a trap to cleanup when a child exits. We either exit when
# the Wine tests are complete, or the timeout happens; whichever
# comes first
set -m
trap cleanup CHLD
# Run the actual tests
$TMPGITDIR/wine $TMPGITDIR/programs/winetest/winetest.exe.so -c -t $TAG
wine.log 21
# Set a timer to force an exit after $TIMEOUT
sleep $TIMEOUT
Re: What to do when un-nominating bugs for 1.2
Hey Dan, Dan Kegel wrote: In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? Alexandre expressed a preference that the bugs not be auto rolled to 1.4; he'd rather we deliberately chose bugs to go into 1.4. So when we un-nominated, we were intentionally returning bugs to the larger pool. If that proves to have been a mistake (which it may yet), please blame me; I made Austin make each change. We were trying an experiment - a bug council to review the bugs. I'm not sure if it was successful; the bugs have a great richness of information that is hard to digest and then discuss thoughtfully in a relatively small (2 hours) period of time. Cheers, Jeremy
Re: [oleaut32] StructArg tests cannot rely on an unpacked structure memcmp.
Austin English wrote: On Sat, Oct 24, 2009 at 5:13 PM, Jeremy White jwh...@codeweavers.com wrote: Has the side effect of preventing a test failure which occurs only when running with +heap. Woohoo! Should fix: http://bugs.winehq.org/show_bug.cgi?id=14078 No; this patch doesn't address that particular Valgrind issue (the heap warning and the valgrind issue are, I'm fairly certain, not related). http://bugs.winehq.org/show_bug.cgi?id=17412 But this one should be done if this patch goes in. Cheers, Jeremy
tmarshal patch for consideration
On route to trying to fix the +heap warning, I actually
fixed it first by using the attached patch.
I believe this patch is correct; it makes any error in the
marshaling process sufficient to prevent an actual invocation.
However, it's a fairly fundamental behavior change, and I don't
know this code, so I thought I'd see if anyone objected before
I submitted it.
As far as I can tell, the behavior currently is that if we
can't demarshal a particular argument in a typelib, we go ahead
and call the function anyway. This could conceivably have
'good' side effects if the arguments we can't demarshall aren't used
by the caller.
The new behavior would be to fail anytime we don't understand
a parameter in the typelib. That seems better to me, but again,
I'm really new to this code, so kibitzing appreciated.
Cheers,
Jeremy
From 7ba53d98859fb3fac7cc883e44f415e7982adc52 Mon Sep 17 00:00:00 2001
From: Jeremy White jwh...@codeweavers.com
Date: Sat, 24 Oct 2009 14:11:05 -0500
Subject: [PATCH] Report errors when [un]marshalling unknown types.
---
dlls/oleaut32/tmarshal.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/dlls/oleaut32/tmarshal.c b/dlls/oleaut32/tmarshal.c
index e7d7b89..e81de94 100644
--- a/dlls/oleaut32/tmarshal.c
+++ b/dlls/oleaut32/tmarshal.c
@@ -909,7 +909,7 @@ serialize_param(
}
default:
ERR(Unhandled marshal type %d.\n,tdesc-vt);
- return S_OK;
+ return E_FAIL;
}
}
@@ -1248,7 +1248,8 @@ deserialize_param(
for (i=0;iadesc-cDims;i++)
arrsize *= adesc-rgbounds[i].cElements;
for (i=0;iarrsize;i++)
- deserialize_param(
+ {
+ hres = deserialize_param(
tinfo,
readit,
debugout,
@@ -1257,6 +1258,9 @@ deserialize_param(
(DWORD*)((LPBYTE)(arg)+i*_xsize(adesc-tdescElem, tinfo)),
buf
);
+ if (hres)
+ return hres;
+ }
return S_OK;
}
case VT_SAFEARRAY: {
@@ -1271,7 +1275,7 @@ deserialize_param(
}
default:
ERR(No handler for VT type %d!\n,tdesc-vt);
- return S_OK;
+ return E_FAIL;
}
}
}
@@ -2128,7 +2132,7 @@ TMStubImpl_Invoke(
xargs += _argsize(elem-tdesc, tinfo);
if (hres) {
ERR(Failed to deserialize param %s, hres %x\n,relaystr(names[i+1]),hres);
- break;
+ goto exit;
}
}
--
1.5.6.5
Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
Dan Kegel wrote: I think your approach is peachy, but Alexandre wanted a version check; look at his most recent post in this thread: Alexandre wanted a version check when asked a different question. That question was when would we prefer an available native Richedit over the builtin one. (i.e. in the LoadLibrary(riched20) case). I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name. Cheers, Jeremy
Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
Alexandre Julliard wrote: Dan Kegel d...@kegel.com writes: OK, so even on an absolute path, we need to do a version check, and only use the bundled copy if it's newer than builtin? (That's what I thought you meant earlier.) Yes, and even that may not be enough, it may have to be limited further to some very specific cases. How do we go about identifying those specific cases? Should we start with a list of dlls (with one entry in the list - riched20)? Cheers, Jeremy
Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
I think we never pursued the question Dan posed in this subject line. That is, Powerpoint 2007 makes the following call: Call KERNEL32.LoadLibraryA(0033c0a8 C:\\Program Files\\Common Files\\Microsoft Shared\\office12\\riched20.dll) It's clearly trying to load it's private dll. Instead of loading that private copy, we load the builtin riched20 instead. The builtin isn't 'good enough', and Powerpoint fails. Isn't that wrong? Shouldn't we prefer an explicitly referenced native dll to a builtin, even in builtin,native load order? The attached proof of concept patch allows Powerpoint to display the troubled presentation. If I am on the right track, does it make sense to add a conformance test to create a bare bones %TEMP%\riched20.dll and load it? Cheers, Jeremy diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c index 71d7ecd..ef66b50 100644 --- a/dlls/ntdll/loader.c +++ b/dlls/ntdll/loader.c @@ -1977,6 +1977,9 @@ static NTSTATUS load_dll( LPCWSTR load_path, LPCWSTR libname, DWORD flags, WINE_ case LO_DEFAULT: /* default is builtin,native */ nts = load_builtin_dll( load_path, filename, handle, flags, pwm ); if (!handle) break; /* nothing else we can try */ +/* file is not a builtin library, if we we have a real file, try native */ +if (nts == STATUS_INVALID_IMAGE_FORMAT handle loadorder != LO_BUILTIN) +nts = load_native_dll( load_path, filename, handle, flags, pwm ); /* file is not a builtin library, try without using the specified file */ if (nts != STATUS_SUCCESS) nts = load_builtin_dll( load_path, filename, 0, flags, pwm );
Wineconf drumbeat - don't sleep on the streets!
Hi Folks, It's now close enough to November that you can't blow this email off grin. We've got all the info here: http://wiki.winehq.org/WineConf2009 Our challenge this year is that we're managing the booking, so we need a firm head count ahead of time. Again, if money is an issue, and you haven't already, please contact me privately. So if you're thinking of coming, email Hans. Now. Please. Failure to do so may result in your sleeping on the streets of Enschede *grin*. Cheers, Jeremy
Re: Wineconf drumbeat - don't sleep on the streets!
Just how does one switch the PayPal interface to Euro I wonder ;) Actually, Paypal takes Euros just fine (we use it at CodeWeavers), but it was rather remiss of me to not set that up *first* :-(. I need to connect with the SFC guys to get that set, so bear with me for a few days while I iron that out. Cheers, Jeremy
Fun news about CodeWeavers
http://www.codeweavers.com/about/general/press/20090724/ *grin* Cheers, Jeremy
Re: cd-roms that need unhide
What say? Would this help users more than it would hurt? Dan, can you just quick check the file system type? If it's UDF, then it's a known issue. I basically need to do my patch again, but for the UDF file system. My original work was just for ISO9660; I failed to realize that DVDs had their own format :-(. This is on my todo list, but it hasn't moved for 10 or 12 months. It'd be a relatively straightforward job if someone else wanted to do it. (The hard part isn't writing the patch; the hard part is getting it committed). Cheers, Jeremy
Wineconf 2009 and funding
What is the status of the Wine Party Fund this year, to help with the cost of transportation/lodging? I remember quite a bit of it was used up last year... I see no reason to change the practice of providing travel sponsorships. I believe the WPF is lower this year than last, so we may be more restrained in what we can offer, but folks should definitely ask me if they're interested. Cheers, Jeremy
Re: /. wants a fork
Not sure, but I see the second time around was a success for him.. First attempt on the subject : http://slashdot.org/firehose.pl?op=viewid=4193755 http://slashdot.org/firehose.pl?op=viewid=4193755 Ah. I see; he apparently believes that CrossOver has a DIB Engine and we've been holding out all these years. That's why he decided we were evil. /me goes to review Huw's commits to find the one where he snuck a DIB Engine into CrossOver without my knowing it grin. Cheers, Jeremy
Re: Wine patch code review or what to do if patches get stuck?
Sometimes no feedback means that you just dont know - is there something wrong? Or maybe your patch wos not understood correctly? Or there are doubts that what you did is right? Or what? It would be better to have feedback like are you serious? than nothing at all :) I've tried to update the 'why was my patch ignored' section in the Wiki: http://wiki.winehq.org/DeveloperFaq#head-1e5a50563dbdb221702cbde246b23f5de08a75e9 to reflect what I understand from Alexandre. Not sure if any of it applies in your case, but I thought it'd be good to have it in the mailing list archives. Cheers, Jeremy
Re: Janitor: list.h functions defined but not used
Glenn L. McGrath wrote: Hi all, im new to the list, im interested in grinding away at some of the warnings wine generates... Welcome to Wine, and thanks! Be cautioned that open source projects can be brutal and mean places. I think Wine is one of the nicer ones, but that mostly means that our common evil is to ignore you. Please don't feel hurt if that happens; I'd suggest reading the web site for hints if you get stymied, and hanging out on irc at #winehackers is often a good way to get more informal and chatty help. Cheers, Jeremy
Re: SOC 2009: Application Test Suite
Roderick Colenbrander wrote: Hi Austin, Not sure if you are aware of it but there is also cxtest which was written by codeweavers under the gpl. See http://cxtest.ifne.eu:82/ it seems they (still?) use it regulary to track regressions. I haven't looked at it and don't know that autohotkey stuff but how do both differ? Wouldn't it be better to continue with cxtest? Or perhaps it would be better to use autohotkey (assuming it is a widely used app) and extend it so that cxtest can be dropped. Actually, afair, the thinking was that autohotkey would be a nice complement to cxtest. That is, if you can write an autohotkey test that works nicely on a single application on Windows, in theory, you can drop it into a cxtest frame work and get all of the error tracking and automated bisecting and fun stuff we've done with cxtest. Also, I haven't pursued it a lot, but we now have cxtest running the Mozilla and OpenOffice test suite against Wine. You can see those results here: http://cxtest.ifne.eu:82/wine-error-ratio They're hard to understand, but the IFNE guys would *love* to have someone take an interest in it and explain it to them. The numbers are somewhat encouraging; roughly 50,000 tests run, and about 97% of them correctly (the majority of the delta are just unknown). What's nice is that, in theory, cxtest can detect any regressions any auto-bisect for guilty patches. Cheers, Jeremy
Status of TWAIN and SANE
Alexandre is right; text files that bit rot are a rotten way to report status. Better is to write verbose emails that make people click delete quickly grin. I've been working on improving Wine's scanner support for the past few weeks, and it's come a long way. If anyone has a scanner, and wants to help me out, I'd sure appreciate testing. We could use other applications and other sane scanners as test data points. So here is a current status: What works For Me (TM): 1. Most of what the TWAIN 1.8 specification defines as mandatory is now implemented. I'll document the exceptions in the code shortly. 2. Scanning with IrfanView and Acrobat Professional seems to mostly behave. What doesn't work: 1. You can't use advanced Twain features like file transfer mode. 2. Memory xfer mode is almost certainly broken. 3. Acrobat lets you set a custom scan size, which we don't support (see DAT_IMAGELAYOUT, below). If anyone else wants to play, I'd appreciate it. Cheers, Jeremy
Re: dlls/userenv: fixed stubs GetUserProfileDirectoryW/A (4)
Much less important but still: please remove trailing whitespaces. 'git apply' should not produce any warnings. I've discovered that if you use git-add to fully stage your commit, you can then run: git-diff-index --check HEAD immediately prior to committing; that will catch such warnings while it's easy to fix them. Cheers, Jeremy
Re: [sane.ds 4/4] More correctly detect an end of scan job from sane; this enables Acrobat to pull multiple pages in one scan.
Sorry; I made a basic mistake (failed to check --without-sane). Resending hopefully corrected patch. Cheers, Jeremy
Re: twain_32/tests: Link with twain_32.dll.
Francois Gouget wrote: --- winetest can detect if twain_32.dll is there or not, and if it's missing there's nothing to test anyway. Note that make_makefiles will need to be run. This patch breaks make crosstest for me: [apevia:~/w/wine/dlls/twain_32/tests] make crosstest i586-mingw32msvc-gcc dsm.cross.o testlist.cross.o -o twain_32_crosstest.exe -L../../../dlls -L../../../dlls/twain_32 -L../../../dlls/user32 -L../../../dlls/gdi32 -L../../../dlls/kernel32 -ltwain_32 -luser32 -lgdi32 -lkernel32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -ltwain_32 collect2: ld returned 1 exit status make: *** [twain_32_crosstest.exe] Error 1 (it also breaks make test for me, but that may be operator error). But, what's more, I do not see the point. Twain_32 is not a Microsoft DLL; it is not present by default on most Windows systems. Further, the API specifications are quite clear: you're supposed to LoadLibrary Twain32, and all Twain applications I've tested do so. I don't see the benefit in making our test behave differently than the recommended behavior for this DLL. Cheers, Jeremy
Re: Wine download page usability problem
I think we should also move the text This endorsement is the primary recognition that CodeWeavers has requested in exchange for hosting the Wine web site. to the bottom of the page, and change it to read Thanks to CodeWeavers for hosting WineHQ.org. +1 To be very honest, that would hurt. We get an appreciable amount of traffic from that more prominent location, and that traffic helps to pay our salaries. I feel that it is reasonable for us to ask for that prominent placement, given our contributions, particularly since we're quite honest and clear about it. Cheers, Jeremy
Re: Wine download page usability problem
No argument there, but the thing you want prominently placed is the download link, not the thankyou, right? Oh, sorry; I didn't understand. I was trying to be honorable on this point by clearly revealing why that prominent placement was given to us; a truth in advertising sort of thing. I can see that it consumes vertical white space, and I can get over myself. I remove my objection :-/. Cheers, Jeremy
[Fwd: Windows on Linux App of the Year]
We've won the 'Windows on Linux' award of the year on LinuxQuestions.org again (by quite a large margin, I might add). Woohoo! Cheers, Jeremy ---BeginMessage--- Jeremy, Hope you've been well. It's my pleasure to inform you that wine has once again been selected as the Windows on Linux App of the Year in the 2008 LinuxQuestions.org Members Choice Awards. Congratulations! For more information, visit: http://www.linuxquestions.org/questions/2008-linuxquestions.org-members-choice-awards-83/windows-on-linux-app-of-the-year-695655/ I've attached an official website badge. If you have any questions, let me know. --jeremy http://jeremy.linuxquestions.org/ attachment: windows-linux-app-wine.png---End Message---
Re: [sane.ds try2 1/3] Get resolution from sane, instead of hard coding -1.
Hi Juan, The other comment is, is adding a new file (option.c) really necessary? If you're planning to expand it a lot, perhaps, but just for this one small function it looks like overkill to me. This remark still stands. Yes, I am planning on expanding options.c a fair amount, and I'm going to need that functionality in at least 2 of the existing files in sane.ds, so I thought it should go in another file. Cheers, Jeremy
Re: [sane.ds 1/3] Get resolution from sane, instead of hard coding -1.
I'm sorry; I failed to do a git-add options.c prior to this commit.
Please use this patch instead.
Cheers,
Jeremy
From d0c4a185b93a8b3040f4b7ffc001fa3f8f7b0199 Mon Sep 17 00:00:00 2001
From: Jeremy White jwh...@codeweavers.com
Date: Thu, 12 Feb 2009 16:22:46 -0600
Subject: [PATCH] Get resolution from sane, instead of hard coding -1.
To: wine-patches wine-patc...@winehq.org
---
dlls/sane.ds/Makefile.in |3 +-
dlls/sane.ds/ds_image.c |7 -
dlls/sane.ds/options.c | 47 ++
dlls/sane.ds/sane_i.h|4 +++
4 files changed, 58 insertions(+), 3 deletions(-)
create mode 100644 dlls/sane.ds/options.c
diff --git a/dlls/sane.ds/Makefile.in b/dlls/sane.ds/Makefile.in
index d8646fe..245c42e 100644
--- a/dlls/sane.ds/Makefile.in
+++ b/dlls/sane.ds/Makefile.in
@@ -11,7 +11,8 @@ C_SRCS = \
ds_ctrl.c \
ds_image.c \
sane_main.c \
- ui.c
+ ui.c \
+ options.c
RC_SRCS = \
rsrc.rc
diff --git a/dlls/sane.ds/ds_image.c b/dlls/sane.ds/ds_image.c
index 9a88bb5..5bb6cbb 100644
--- a/dlls/sane.ds/ds_image.c
+++ b/dlls/sane.ds/ds_image.c
@@ -86,6 +86,7 @@ TW_UINT16 SANE_ImageInfoGet (pTW_IDENTITY pOrigin,
TW_UINT16 twRC = TWRC_SUCCESS;
pTW_IMAGEINFO pImageInfo = (pTW_IMAGEINFO) pData;
SANE_Status status;
+SANE_Int resolution;
TRACE(DG_IMAGE/DAT_IMAGEINFO/MSG_GET\n);
@@ -111,9 +112,11 @@ TW_UINT16 SANE_ImageInfoGet (pTW_IDENTITY pOrigin,
activeDS.sane_param_valid = TRUE;
}
-pImageInfo-XResolution.Whole = -1;
+if (sane_option_get_int(activeDS.deviceHandle, resolution, resolution) == SANE_STATUS_GOOD)
+pImageInfo-XResolution.Whole = pImageInfo-YResolution.Whole = resolution;
+else
+pImageInfo-XResolution.Whole = pImageInfo-YResolution.Whole = -1;
pImageInfo-XResolution.Frac = 0;
-pImageInfo-YResolution.Whole = -1;
pImageInfo-YResolution.Frac = 0;
pImageInfo-ImageWidth = activeDS.sane_param.pixels_per_line;
pImageInfo-ImageLength = activeDS.sane_param.lines;
diff --git a/dlls/sane.ds/options.c b/dlls/sane.ds/options.c
new file mode 100644
index 000..764b104
--- /dev/null
+++ b/dlls/sane.ds/options.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2009 Jeremy White jwh...@codeweavers.com for CodeWeavers
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include config.h
+
+#include stdlib.h
+#include twain.h
+#include sane_i.h
+#include wine/debug.h
+
+WINE_DEFAULT_DEBUG_CHANNEL(twain);
+
+SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val)
+{
+SANE_Status rc;
+SANE_Int optcount;
+const SANE_Option_Descriptor *opt;
+int i;
+
+rc = psane_control_option(h, 0, SANE_ACTION_GET_VALUE, optcount, NULL);
+if (rc != SANE_STATUS_GOOD)
+return rc;
+
+for (i = 1; i optcount; i++)
+{
+opt = psane_get_option_descriptor(h, i);
+if (opt (opt-name strcmp(opt-name, option_name) == 0)
+ opt-type == SANE_TYPE_INT )
+return psane_control_option(h, i, SANE_ACTION_GET_VALUE, val, NULL);
+}
+return SANE_STATUS_EOF;
+}
diff --git a/dlls/sane.ds/sane_i.h b/dlls/sane.ds/sane_i.h
index 5a3a6d0..5938eef 100644
--- a/dlls/sane.ds/sane_i.h
+++ b/dlls/sane.ds/sane_i.h
@@ -211,4 +211,8 @@ TW_UINT16 SANE_RGBResponseSet
BOOL DoScannerUI(void);
HWND ScanningDialogBox(HWND dialog, LONG progress);
+/* Option functions */
+SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val);
+
+
#endif
--
1.5.6.3
Re: imagicos
EA Durbin wrote: I just saw this linux distribution on distrowatch. They claim to be able to run all microsoft products. Interesting. Just for the record, these folks are customers of ours. It is my belief that their distribution of CrossOver complies with all of the terms of the LGPL; we try to make sure of that for our customers. I even believe that money they make as a result of their windows compatibility will, albeit fairly indirectly, support Wine development. Obviously, I like it when folks can celebrate the contributions of everyone to Wine, and to all the FOSS products that go into something like a Linux distribution. But Free Software means that folks are also free to market as they see fit :-/. Cheers, Jeremy
Re: wine.budgetdedicated.com down?
Would it be possible to host the Wine packages somewhere with higher availability? My sense is that budgetdedicated has largely had a stellar track record, and that we should, in addition to our great thanks and praise, give them the benefit of the doubt. Scott, I looped you directly in the hope that you'd chime in as well. Cheers, Jeremy
Re: [twain_32 2/7] Add an interactive set of tests for a selected scanner.
+rc = pDSM_Entry(appid, source, DG_CONTROL, DAT_CAPABILITY, MSG_GET, cap); Bletch. Forgot to add --attach. I'll resend the series. Sorry :-/. Cheers, Jeremy
Re: CreateScalableFontResourceW
I've had a series of patches on this, that I think have been gradually growing less wrong. The 9/17 patches were the last set that were useful by themselves; you should try to get those to apply: http://www.winehq.org/pipermail/wine-patches/2008-September/061696.html My current belief is that the font code needs to be refactored to enable a correct implementation. I submitted that refactoring to wine-devel back in October as an RFC: http://www.winehq.org/pipermail/wine-devel/2008-October/069654.html I believe that a fully correct implementation of CreateScalableFontResource flows from that refactoring and a fairly obvious adjustment of the 9/17 patches. But the importance of this code, my inexperience with it, and the part time nature of my efforts have all led Alexandre to reasonably be very leery of the code. At this point, I am waiting until I have enough time to really focus on it to submit it as a full patch set. I am intending to work on improving the tests around the related code as an intermediate step. But, importantly, it's not likely to see progress in the near term, so your best bet would be to grab the 9/17 patches and attempt to apply them. Cheers, Jeremy
Re: RFC: Proposed new web site design
Hey Tom, That was slick, the mock up listed Bordeaux under third party apps and when the site went live it was somehow removed :D Well, the mockup had a fairly crummy presentation of Bordeaux; I meant to ask Steven to submit a better put together version, with nicer graphics and such, but I forgot. Hopefully this will serve for that. Cheers, Jeremy
Re: RFC: Proposed new web site design
Thanks for all the feedback, folks; I have to admit that was a bit overwhelming. I've read through it all, and have tried to digest it, below. But I think there is a strong sense here that no one likes a web site designed by committee. Given that, I think the plan will be to adjust based on feedback, and then go forward. After all, once we take it live, patches will still be accepted grin. Here is the digest of comments as I saw them: 1. Folks are basically cool with the CodeWeavers positioning; there is some thought we should even provide more information and linkage to our compatibility database. (I think we'll baby step with what we have now). 2. Lots of people hate the secondary scroll bar. 3. People want a longer introduction to Wine. I think it needs to be short and sweet. We'll noodle; suggestions welcome. 4. We should have hovers on the Wiki page (Jer is working on that). 5. Some folks found the grey text a bit hard to read. (I avoid color discussions like the plague; I think it's kind of like emacs vs vi. I just report the news). 6. There was some agitation for more news, more description, and perhaps more visual elements, like a screen shot. 7. There is some concern as to Wine vs WINE I had raised this privately, and was given the back hand of the artiste. I appreciate the work of the artiste, and so have backed off. 8. There were comments about the icons Some folks didn't like the download icon, some folks wanted the icons to pop more when hovered. The artiste is chewing on it. And then, finally, there were some comments on the main text points themselves. Notably, this one from Dan: About What is Wine, and why should I use it? I think that's a good change. In fact, I think we were so focused on the visual elements that we didn't really spend a ton of time on the words and they could be tweaked. and we're missing the user task Will my app work with Wine? which should link to the appdb. I disagree with the second point. I think the top level should remain very simple. The secondary pages can explain that Wine may not run their application, and so the appdb should feature prominently in that explanation. But I think leading with it is part of the slippery slope to too many links. Cheers, Jeremy
RFC: Proposed new web site design
At Wineconf, we made the decision to change the entry page to the Wine web site. The hope was to simplify and stream line it, and to put in place the infrastructure to start moving more content to the Wiki. Jeremy Newman and Jon Parshall have put a lot of time and energy into a proposed new design, following what we took away from the meetings at Wineconf. A mock up of that design is up now here: http://wine.codeweavers.com/winehq_new/ ...and the theming intended for all 'child' pages of the web site, starting with the Wiki: http://wine.codeweavers.com/winehq_new/wiki.html Beyond the normal controversy that any new design sparks there is one major potential controversial change. That is, I am asking for prime placement on the download page on behalf of CodeWeavers instead of the (stale and ugly, sorry) banner ads we used in the past. You can see our current concept around that positioning here: http://wine.codeweavers.com/winehq_new/download.html I hope that the general community sees that as a reasonable exchange for all of the work we put into Wine and hosting the Wine server, and a vast improvement over the banner ads. At any rate, comments and feedback are welcome. And in a vain attempt to prevent all the flames from scorching Jon and Jeremy, I'd like to officially state how much I appreciate their efforts. Cheers, Jeremy
Governance of Wine with respect to the Software Freedom Conservancy
Hi folks, As you may recall, several years ago, we decided to work with the Software Freedom Conservancy to ask them to manage aspects of Wine that merited the shield of a formal organization. They have been great, and a great improvement over our former process. I thought I'd send an email out for the record, expressing what they do for us, and how that is governed. First, there are essentially 2 major assets they manage for us. They manage all funds donated to Wine - the donate button goes into a bank account they manage. They also hold trademarks to the Wine logo that they filed on our behalf. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, Dan Kegel, Alexandre, and myself are in contact with them. The goal is that all 3 of us agree on every decision, but 2 of the 3 of us must concur with any decision before it is effective. We three can appoint anyone else we choose to replace or augment the decision group. All decisions are CC'd to the WWN author (currently Zach Goldberg) for monitoring. The SFC will recognize a 'revolt' by the Wine project. That is, Dan, Alexandre and I can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has either been to pay for conference expenses directly (as in Reading, 2 years ago), or to help defray travel costs for Wine contributors to come to Wineconf (as happened this year). Cheers, Jeremy
Present Wine at CeBit?
Anyone want to give a presentation on Wine at CeBit? http://www.linux-magazine.com/online/news/cebit_open_source_linux_magazine_and_linux_foundation_announce_call_for_projects/(kategorie)/0 If you're interested, email me privately, and I'll connect you with Britta. Cheers, Jeremy
Re: wine users forum registration issue
Not sure what they are complaining about - worked for me first time around. I think some people might have problems with: 1. Entering lower case text instead of caps Well, I'll have Jer add a note to that effect right away. Can't hurt. 2. Not knowing (and not willing to find out) who is the current maintainer. This one, I think, may now be mostly solved. I think Jer made a lot of different things work as an answer and that seems to have reduced the people who miss this one. That does tend to argue against a rotating list of questions, as I don't want to have to tune each question. Bluntly, what we really need is for someone to care and to find out what the problem is, and perhaps to offer solutions. Cheers, Jeremy
Re: wine users forum registration issue
Right. So the forum software is broken, and all of the Wine devs would rather fix Wine than the forums? Sounds like a good case for ditching the forums. I disagree violently. The case for the forums is clear; users prefer them by a rather large amount. If we're going to provide user facing resources on winehq (which I, at least, intend to see happen), then I think the forums are the correct answer. However, with that said, some sort of captcha is a requirement on forums; they really suffer from automatic spam attacks. Does anyone know *why* these people suffer? Is there something specific to their monitor or is it just a general struggle with captchas? Finally, is there someone who would be willing to help users through this? The real problem is that all cries for help to web-admin (for any reason, not just this one) are being ignored. Cheers, Jeremy
Re: Sugared Wine
Hi Markus, Judging by the photoshopped image you put an an Windows-like desktop designed for adults into a desktop designed for childs. Now, if you'd at least hide the original (sugar) desktop you'd re-gain precious screen space and wouldn't have to explain the childs when to use which of both desktops. The photoshopped image is actually not how it works; the actual implementation does run in the whole screen. For me, I've always considered the strength of Wine to provide a seamless integration into the original operating system / desktop and _not_ to come with it's own taskbar / launch system. For the Windows- like experience, I'd always prefer an hardware emulator. Actually, it's interesting, because I have long been of the exact same opinion. I had my mind changed by a somewhat startling event. But first, let me digress. I sustain that there are two kinds of understanding: intellectual, and emotional. The example I always use is that when my wife and I went to buy luggage years ago, she reported that her friends told her it sucked to have black luggage, because everyone has black luggage. I agreed, so we looked for red or green, but they were out. All they had was black. So I said, what the heck, how bad can it be? And we bought black. So I intellectually understood the problem. But it didn't really *smack* me in the face until, tired and grumpy after traveling, I had to stand hyper vigilant in the baggage claim area, watching 5 separate people pick up my suitcase and put it down again. After that, I *emotionally* understood the problem. I got it in my gut. So, undigressing. I was discussing all of this with John Gilmore, a very smart man. He and I were talking about Wine, and why Wine was not of more use to the OLPC community. Hashing through this, I suggested the mock up that is posted as a screen shot on the Sugared Wine Wiki. John immediately lit up. He exclaimed: Why hasn't Wine had this all along!?!?! Okay, I talked him down, and he did come to understand why a dedicated desktop was a stupid idea for a normal Linux user. But the key point was that he immediately and *emotionally* was grabbed by the value of Wine. And I've tried this on a bunch of people since. And it works exactly the same way. That one picture gets people more in their gut than any other explanation of Wine I've ever used. I hate it - it's the exact same image that competitors like Parallels and VMWare use. And Wine is fundamentally different from and better than PC emulation technology. But the bottom line is that we're human, and our brains work in funny ways. And the goal of the Sugared Wine project is to show people considering Sugar instead of a Windows XP based system that Wine is a viable option to consider. So getting them in the gut is a really important part of the project. Once we've hooked them, then we can help work with them to package whatever application they need to run as a proper XO activity bundle. Cheers, Jeremy
Favor: review refactor of gdi32/freetype.c - AddFontToList
So in my ongoing quest to get CreateScalableFontResource completed, I
believe that I need to refactor gdi32/freetype.c - AddFontToList to
expose an interface to allow me to retrieve a Face *.
Attached is a series of 4 patches that accomplish what I believe to be a
reasonable refactoring of that function.
From my analysis, the only material change in the logic flow is that the
old code would skip a face that existed prior to building the new Face *
structure. The new code goes ahead and builds up a proposed Face *
before testing to see if the proposed new Face should be skipped.
It passes the font tests and notepad still runs, but I recognize that
this is a much more invasive change than I am really qualified to make.
I would appreciate others with expertise in this area reviewing this
series. Also, if there is advice on a standard bevy of tests I could
run, I would appreciate it. There is a fair amount of special case
logic in this function, and I know that our regression tests do not
exercise it all.
Thanks,
Jeremy
From 03033f6e29df9d57ba9fc9232ebe648436d84458 Mon Sep 17 00:00:00 2001
From: Jeremy White [EMAIL PROTECTED]
Date: Thu, 9 Oct 2008 12:47:52 -0500
Subject: [PATCH] Move the FreeType face creation logic to a separate function.
To: wine-patches [EMAIL PROTECTED]
---
dlls/gdi32/freetype.c | 146 +++--
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
index 0ab4c7a..55288a7 100644
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
@@ -1186,6 +1186,83 @@ static void AddFaceToFamily(Face *face, Family *family)
#define ADDFONT_EXTERNAL_FONT 0x01
#define ADDFONT_FORCE_BITMAP 0x02
+static INT GetFtFace(const char *file, void *font_data_ptr, DWORD font_data_size, char *fake_family, DWORD flags, FT_Long face_index, FT_Face *ft_face)
+{
+FT_Error err;
+TT_OS2 *pOS2;
+
+if (file)
+{
+TRACE(Loading font file %s index %ld\n, debugstr_a(file), face_index);
+err = pFT_New_Face(library, file, face_index, ft_face);
+} else
+{
+TRACE(Loading font from ptr %p size %d, index %ld\n, font_data_ptr, font_data_size, face_index);
+err = pFT_New_Memory_Face(library, font_data_ptr, font_data_size, face_index, ft_face);
+}
+
+if(err != 0) {
+WARN(Unable to load font %s/%p err = %x\n, debugstr_a(file), font_data_ptr, err);
+return 0;
+}
+
+if(!FT_IS_SFNT((*ft_face)) (FT_IS_SCALABLE((*ft_face)) || !(flags ADDFONT_FORCE_BITMAP))) { /* for now we'll accept TT/OT or bitmap fonts*/
+WARN(Ignoring font %s/%p\n, debugstr_a(file), font_data_ptr);
+pFT_Done_Face(*ft_face);
+return 0;
+}
+
+/* There are too many bugs in FreeType 2.1.9 for bitmap font support */
+if(!FT_IS_SCALABLE((*ft_face)) FT_SimpleVersion ((2 16) | (1 8) | (9 0))) {
+WARN(FreeType version 2.1.9, skipping bitmap font %s/%p\n, debugstr_a(file), font_data_ptr);
+pFT_Done_Face(*ft_face);
+return 0;
+}
+
+if(FT_IS_SFNT((*ft_face)))
+{
+if(!(pOS2 = pFT_Get_Sfnt_Table(*ft_face, ft_sfnt_os2)) ||
+ !pFT_Get_Sfnt_Table(*ft_face, ft_sfnt_hhea) ||
+ !pFT_Get_Sfnt_Table(*ft_face, ft_sfnt_head))
+{
+TRACE(Font %s/%p lacks either an OS2, HHEA or HEAD table.\n
+ Skipping this font.\n, debugstr_a(file), font_data_ptr);
+pFT_Done_Face(*ft_face);
+return 0;
+}
+
+/* Wine uses ttfs as an intermediate step in building its bitmap fonts;
+ we don't want to load these. */
+if(!memcmp(pOS2-achVendID, Wine, sizeof(pOS2-achVendID)))
+{
+FT_ULong len = 0;
+
+if(!load_sfnt_table(*ft_face, FT_MAKE_TAG('E','B','S','C'), 0, NULL, len))
+{
+TRACE(Skipping Wine bitmap-only TrueType font %s\n, debugstr_a(file));
+pFT_Done_Face(*ft_face);
+return 0;
+}
+}
+}
+
+if(!(*ft_face)-family_name || !(*ft_face)-style_name) {
+TRACE(Font %s/%p lacks either a family or style name\n, debugstr_a(file), font_data_ptr);
+pFT_Done_Face(*ft_face);
+return 0;
+}
+
+if((*ft_face)-family_name[0] == '.') /* Ignore fonts with names beginning with a dot */
+{
+TRACE(Ignoring %s since its family name begins with a dot\n, debugstr_a(file));
+pFT_Done_Face(*ft_face);
+return 0;
+}
+
+return 1;
+
+}
+
static INT AddFontToList(const char *file, void *font_data_ptr, DWORD font_data_size, char *fake_family, const WCHAR *target_family, DWORD flags)
{
FT_Face ft_face;
@@ -1196,7 +1273,6 @@ static INT AddFontToList(const char *file, void *font_data_ptr, DWORD font_data_
Family *family;
Face *face;
struct list *family_elem_ptr, *face_elem_ptr;
-FT_Error err;
FT_Long face_index = 0, num_faces;
#ifdef
Re: gdi32: Add more font substitution tests, make them pass under Wine
Dmitry, This patch has triggered a bug in make test for me; I only notice it when I put a Windows flavor of arial.ttf into my windows/fonts directory. The specific failure is in get_glyph_indices when we're passing in a symbol charset (i.e. the 3rd loop). I've tracked it to line 3461 of gdi32/freetype.c. Specifically, the lfWeight is set to FW_DONTCARE but the charset is Symbol. Git-blame pointed at this patch. I find that if I modify tests/font.c to set a lfWeight of normal in get_glyph_indices, then the tests no longer fail. However, the test passes on Windows XP without needing that change, so I'm afraid that this code must be wrong. Here are the full commit details: commit a5d288f08c08dc19d217093fdf8622605c92a4e0 Author: Dmitry Timoshkov [EMAIL PROTECTED] Date: Tue May 13 22:10:05 2008 +0900 gdi32: Add more font substitution tests, make them pass under Wine. I was hoping that a resolution to this would be obvious to you, as you clearly understood this issue in depth when you wrote the patch. Cheers, Jeremy
Re: Wineconf follow up: Cosmetic website changes
Oh, I don't know. Seems to me that the wiki it's a *better* landing page for newbies; it does a better job of leading them by the hand without making them scroll or click. I disagree. People still have an expectation that a 'front page' has some sort of introductory component to it. And even users expect to need to go to a front page, I think they would almost be caught off guard to be thrown straight into a Wiki. (You almost need the motivator of 'trouble running Wine? go here!'). And I don't like the notion that users somehow get to trump all other potential uses of the web page. If it directs users to information well, it's not aesthetics, it's usability. The idea is to use the front page to quickly handle the most frequent questions (how to get it, where's the doc), and if that's not what they're after, to direct them to a page based on their 'role' (e.g. user or developer). But this I do agree with. Cheers, Jeremy
Re: Bug squish party!
I completely forgot to write to the broader list to let you know that we successfully added 1 more machine - Stefans - to the list of computers that run make test successfully. (We also got James Hawkins Windows box down to 1 failure, and eliminated an enormous number of other test failures). I forgot to let you know because we were all way too busy celebrating at the bar grin. But thanks, and hurray! I definitely agree with Dan that we should make these more frequent than once a year events. Conceivably, we could soon have 3 (gasp!) computers that ran make test to completion grin. Cheers, Jeremy
Discussion of bug versions
We discussed bugzilla versions at Wineconf, re: http://bugs.winehq.org/show_bug.cgi?id=12728 There were several points of consensus. First, it would be helpful if we could reduce the number of versions visible in the drop down box when entering a new bug. That would seem to require a bugzilla code change, though. Anyone know of an easy way to accomplish this? Second, we'd like new bug reporters to not be able to use the 'CVS/GIT' version choice, but to instead be encouraged to report the current version. (wine --version reports something that is easy to match up to the choices). Obviously, it seems that it would be really nice if, when we did that, it was a lot easier to find 1.1.5... Cheers, Jeremy
Wineconf - final reminder!
Folks, Just 11 days until Wineconf. Come celebrate Wine 1.0! http://wiki.winehq.org/WineConf2008 I'll start up a thread for RSVPs and such on the wineconf mailing list. Cheers, Jeremy
Summer of code - thank you Maarten
Just as a complete side note, I have been very impressed at how well organized SOC has been this year, and I blame Maarten grin. I've really appreciated seeing the regular calls for updates, and the follow through that has resulted. Nicely done, and thank you Maarten! Cheers, Jeremy
Re: winequartz.drv Mac OS X UI discontinued?
We probably curse his decisions as much or more than any Wine developer, and whether or not Objective C *blush* Teach me to send email late at night on a foreign computer. The point is that CodeWeavers has no control over whether or not Emmanuel's code goes into Wine. That's entirely Alexandre's decision. Cheers, Jeremy
Re: winequartz.drv Mac OS X UI discontinued?
Hi, Maybe this could be further queried as: What is CodeWeaver's offical stance on supporting a Mac OS X native user interface when the code becomes stable and supportable? and Would CodeWeavers consider bringing Emmanuel on as a paid employee at that time to ensure that the code is maintained? We are very interested in Wine having a more native OS X interface. However, our analysis is that the task is difficult and will require a long time to stabilize and get right. I am excited by and interested in Emmanuel's work, but I am told not to be too excited, that it's not a magic bullet, and that the bulk of the hard work is still ahead. We have a long history of hiring proven Wine developers and thereby sponsoring their work. We do that as much as our income will allow, gated by peoples ability and willingness to work with us. To answer the seemingly implied question: Are we deliberately crippling Wine for Mac OS X to serve our own nefarious ends, the answer is no. That's in no small part because our main nefarious end is to improve Wine :-). Did we make a decision to focus on an X11 based solution for Mac OS X? Yes, for the time being. The advantages are that it's here now, works now, and that most of what we do now also benefits Linux and other platforms. The disadvantage, apparently, is that people suspect us of all kinds of nefarious plots... And, on a final note, just so its clear: the contract between CodeWeavers and Alexandre is very explicit: CodeWeavers gets *no* say in what does or does not go into Wine. We probably curse his decisions as much or more than any Wine developer, and whether or not Objective C Cheers, Jeremy
Announcing dates and location for Wineconf 2008
Hi Folks, Thanks to the volunteer efforts of James Ramey (new guy in our office), we now have a great venue for WineConf 2008. I've put together a page on it here: http://wiki.winehq.org/WineConf2008 The key details are that it will be over the weekend of September 27 and 28, at a hotel in Bloomington, MN. I promise that it won't be mind numbingly cold, and I won't make any one traipse to see an ice palace this year grin. In fact, it's a nice hotel, quite close to the airport, the Mall of America, a Wildlife refuge, and to a stop for our light rail system. Additionally, I believe we will be able to offer fairly substantial travel sponsorships for people that find the cost of travel prohibitive. Email me privately if that would be a help. And for those Europeans that hate US policies, I'll point out two things: 1. January 20, 2009 is fast approaching. 2. 1 Euro gets you $1.60, which is a whole lot of cheap beer At any rate, if you're interested in coming to Wineconf this year, please visit the Wiki and sign up for the wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf We generally use that list for minutiae to avoid spamming the broader mailing list. Hope to see you in September! Cheers, Jeremy
Celebrating Wine 1.0
Woohoo Alexandre just posted the Wine 1.0 commit! I eagerly did my git update and enjoyed running 'wine --version'. Ooo. I'm going to do it again... Let us all have a moment of silence to mourn the passing of the Wine 1.0 jokes grin. Seriously, this is a major milestone for the Wine project. It is no small undertaking to create a complex Free Software project, and to bring it to a state of general usefulness. There are literally millions - if not more - people using this software we have built. This is a great accomplishment, and we all should be deeply proud of what we've accomplished. I think it's particularly important to thank each and every one of the 1076 AUTHORS and to recognize the support and work of the many people that have contributed to Wine without having their name in that file. I also think we should particularly take a moment to recognize the incredible work of our fearless leader - Alexandre Julliard - without whom none of this would have been possible. And then we should celebrate! I realize that any real large communal celebration will have to wait until we can gather for Wineconf. But I intend to gather up a gang of folks and go out for a meal to celebrate. I will lift a glass of Wine in toast to Alexandre and the many people that have worked on Wine, and I encourage everyone else to do the same. Ideally, people will become sufficiently happy to wax maudlin and we can capture all kinds of embarrassing stories on #winehackers grin. Cheers, Jeremy
Re: Website down
Austin English wrote: Did we get slashdotted/dugg to death? Not quite death, but it's pretty tough sailing right now. I think we could have handled one or the other, but both together are apparently more than our current systems can handle. We've stopped mysqld for the moment to try to ride through this; still trying to figure out if there is a simple way to get it through this hump. (Both Digg and /. have really short curves; the demand will be down within hours, and we can go back to business as usual). Cheers, Jeremy
Re: winetest failure summary for 1.0rc2
kernel32:path is mostly path.c:899:TMP=c:\windows\temp...path.c:1178: Test failed: expected buf[0] upper case letter got c, probably people whose ~/.wine is old and has a windir that starts with a lowercase drive letter?! Has that changed recently? I don't think it can be a stale .wine; presuming those were all done with dotests, it creates a new wineprefix for each run. Cheers, Jeremy
Re: winetest failure summary for 1.0rc2
I wanted to reply to that post, but /. locked me out. If anyone else wants to do it, here's what I was going to say: They shifted to new servers tonight, probably had something to do with it. I plagiarized your post completely. Cheers, Jeremy
Thunderbird warning repeat - use --attach
So it seems as though every month or so, some id10t is bit by the Thunderbird bug where it mangles perfectly reasonable looking git-format-patch drafts. This month, I won the prize! :-) I had always habitually done --attach, because that's what GitWine says to do. But after scratching my head, reading man pages, and checking my drafts, I decided that was lame; inline is always nicer, and I dropped the --attach. Big mistake; the draft may look okay, but the end result is mangled somehow. Thanks to Dmitry for alerting me. I've filed a bug with Mozilla over this: https://bugzilla.mozilla.org/show_bug.cgi?id=435020 My sense is that its a subtle bug of some kind; I've had a hard time articulating a strategy to reproduce it (which, by Occam's razor, immediately suggests I'm just missing something :-/). So if others are bit by this and can share any clues or tips for the Mozilla devs on how to reproduce it, I'd appreciate it. Cheers, Jeremy
Re: Thunderbird warning repeat - use --attach
Steven Edwards wrote: On Wed, May 21, 2008 at 11:39 AM, Jeremy White [EMAIL PROTECTED] wrote: So it seems as though every month or so, some id10t is bit by the Thunderbird bug where it mangles perfectly reasonable looking git-format-patch drafts. This month, I won the prize! :-) You mean your not using outlook for your email. =P Outlook 2007 (even on Windows) chokes on my (rather large) IMAP mail box :-(, else I would be...
Re: Most common winetest failures on wine
ntdll:info is a flaky test marked todo_wine that succeeds sometimes:
info.c:822: Test succeeded inside todo block: Expected to read 0
bytes, got 0
Hardy seems to be the common variable for failures, and it seems as though
an actual failure reading from location 0x1234 is the trigger.
(The historically normal case, apparently, is that we succeed in
doing the read).
git-blame points at Peter as the last to touch this.
I've attached a potential patch, hopefully it'll be wrong and force
Peter to step up and fix it correctly grin.
Cheers,
Jeremy
diff --git a/dlls/ntdll/tests/info.c b/dlls/ntdll/tests/info.c
index 9fab806..140be05 100644
--- a/dlls/ntdll/tests/info.c
+++ b/dlls/ntdll/tests/info.c
@@ -819,7 +819,8 @@ static void test_readvirtualmemory(void)
todo_wine{
status = pNtReadVirtualMemory(process, (void *) 0x1234, buffer, 12,
readcount);
ok( status == STATUS_PARTIAL_COPY, Expected STATUS_PARTIAL_COPY, got
%08x\n, status);
-ok( readcount == 0, Expected to read 0 bytes, got %ld\n,readcount);
+if (status == STATUS_PARTIAL_COPY)
+ok( readcount == 0, Expected to read 0 bytes, got %ld\n,readcount);
}
/* 0 handle */
Re: Right way to cope with user error in make test?
Alexandre has said in the past that test failures for an incorrectly or incompletely built wine tree should result in test failures and I agree with this. Yah; I think to some extent we need to wait for Alexandre to express an opinion on how, if at all, he'd like to address this. We seem to have come up with about 4 approaches: 1. Skip the test. Rob thinks Alexandre will reject this 2. Make WINE_NOTICE_WITH be default error; i.e. require an explicit --without in order to skip a package you lack 3. Create some sort of config record; a config.id if you will. This could then be read by dotests and/or winetests to not transmit the results. (As a side note, this might be handy place to put a git HEAD which might allow my winetest patches to go in, thereby eliminating the need for an out of tree dotests. But no bias here grin). 4. Have dotests scan the existing config.log file. Alexandre, do you have a preference? Cheers, Jeremy
Re: Right way to cope with user error in make test?
Hi Alistair,
This could be a good option. libxslt should properly be non-optional
since msxml3 relys on it.
From the Makefile.in, its appears to have linked to libxslt for quite some
time,
but was never an issue since it was never used.
Francois Gouget raised this bug,
http://bugs.winehq.org/show_bug.cgi?id=13035
that libslt should be dynamic, which could be another option.
I think in my case the problem is a bit different; I have the library -
what I don't have are the development headers. Thus the linking all
works, but HAVE_LIBXSLT is not defined, so the transform function
ends up as a stub, and goes on to fail.
And I still don't know a right answer.
The attached patch is one approach - skip the tests in this case.
Does this seem like a reasonable approach to folks?
Cheers,
Jeremy
diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c
index bd45a77..1800531 100644
--- a/dlls/msxml3/tests/domdoc.c
+++ b/dlls/msxml3/tests/domdoc.c
@@ -3242,11 +3242,15 @@ static void test_testTransforms(void)
ok(hr == S_OK, ret %08x\n, hr );
if(hr == S_OK)
{
+#ifdef HAVE_LIBXSLT
BSTR bOut;
hr = IXMLDOMDocument_transformNode(doc, pNode, bOut);
ok(hr == S_OK, ret %08x\n, hr );
ok( compareIgnoreReturns( bOut, _bstr_(szTransformOutput)), Stylesheet output not correct\n);
+#else
+skip(Cannot test transformNode without libxslt headers\n);
+#endif
IXMLDOMNode_Release(pNode);
}
