Re: Generating stats on regression bugs in bugzilla
Austin English wrote: On Fri, Apr 24, 2009 at 6:40 PM, Scott Ritchie wrote: I had a theory that we might be getting better at preventing regressions now than a year or so ago due to the expansion of things like AppDB and the test suite. It'd be nice to have some sort of data though. Would it be reasonable to comb through the bugzilla database for all the bugs tagged regression and analyze them? I'm interested in: 1) quantity and frequency of bugs tagged regression that were filed at various dates since the release of 1.0. I'm not sure whether it's better to use the version number field in bugzilla as a proxy for "first version with regression" or to just guess that from the date. 2) how long regression bugs took to be fixed Thanks, Scott Ritchie It'd be better to use the SHA1SUM of the bad patch, which will give you the day the regression was added. If the fix has the SHA1SUM listed in there as well, it's even easier for you. Some bugs contain the wrong regression before mentioning the correct one. It would be necessary to look for the last SHA1SUM mentioned in a bug to get the correct one. But if the last comment is the fix... you see what I'm saying.
Re: Severity levels
The severity levels are there for guidance. I would hope that common sense would prevail, but clearly it doesn't. If a UI glitch makes a program unusable, then it's normal. I can not believe you need this pointing out to you. http://bugs.winehq.org/show_bug.cgi?id=1347 "Screen is wiped/blanked on usage of DirectDraw (black screen/desktop)" = UI glitch = Sev. Normal Common sense people, that's all that is asked.
Re: Severity levels
Nicklas Börjesson wrote: I am not sure that common sense is the issue. I think it is a question of who you are and what you know. Among the ones submitting bugs now is a quickly rising percentage of normal-to-advanced end users, and that percentage is likely to rise even further, as Linux adoption rates increase. 10 million desktops is the last number I've heard..and people are learning how to report problems. Hell, my mom(77 years old) reported a bug a while ago. My point is, why not adapt the severity levels to the competence level of the submitters instead of having to correct them all the time, creating badwill? Can't the three highest severity levels just be removed? Are they relevant? 1. Blocker "Blocks development and/or testing work" - Is this even possible? Yes. http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Wine&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&resolution=MOVED&bug_severity=blocker&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=%255BBug%2Bcreation%255D&type0-0-0=noop&value0-0-0= 2. Critical "Critical problem that prevents all applications from working" - Possible, if everyone stopped testing code completely, and also unlikely to be reported by a user. No, critical bugs are usually opened by non-Linux users. 3. Major"Major loss of functionality for a wide range of applications - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? No, it's actually what it say, a WIDE RANGE of applications. Then, the severity(or "impact") levels could be: Critical High Medium Low This is way easier to understand for normal people. Also, the definition of each level should not be all that clear(except maybe critical) either, the levels will be discussed anyway, so it is easier to motivate for the developers to grade down a bug without too much discussion. Because the more people start using wine to actually make a living, the more important it will be to them. One would think that vague levels would create more discussion, but according to my experience, and with end-users, it seems to work the other way. And yes, I know that the bug reporting system is used by the developers internally as well, but do you really use the first two levels so often that you need them(I hope not)? As above. Searching for critical bugs would have answered that question. http://bugs.winehq.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Wine&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&resolution=FIXED&resolution=MOVED&bug_severity=critical&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=%255BBug%2Bcreation%255D&type0-0-0=noop&value0-0-0= Bugzilla is to track bugs, it's not a user support forum, and the bugs should be classified as the dev's want them to be classified. That's what this is for: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity Normal: For an application crash or loss of functionality UI glitch or not, if you can't use an app, you can't use it. This is common sense. //Nicklas Your line length needs fixing. "Produced By Microsoft Exchange V6.5" This is why.
Re: Severity levels
Nicklas Börjesson wrote: I think that the users should have quite a say with regards to how important a bug is, because for every user putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ.
Re: Severity levels
IneedAname wrote: On Sat, 2 May 2009 16:52:06 +0200 Nicklas Börjesson wrote: 3. Major"Major loss of functionality for a wide range of applications - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? In that case #16281 would be major not minor, That is if all the applications that has that bug link to it. I think you can not find out how many applications link a bug. As that has not be coded. To find out that information you would have to scan the application data base or change the way the data base holds this data. I think you want to read bug #16284. That would be the "Show Apps affected by this bug" link then. http://appdb.winehq.org/viewbugs.php?bug_id=16281
Re: Severity levels
Nicklas Börjesson wrote: To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ. Yep, but that's more an indication on how much work remains to be done on wine than it is an incorrect severity level. No it isn't. It's an indication on how many people think they're more important than anyone else filing a bug. If Photoshop(the eternal example) should stop working on windows due to a regression, I am sure the users would consider it critical when they report it to Microsoft. It doesn't matter what the users think, we've been over this, it would be up to MS coders. They would put a high priority on it because Adobe it a major player, and I'm sure MS makes a lot of money out of them one way or another. This is a FOSS project and has no bearing on severity levels. If a set of devs decide to work on getting a particular app working that's up to them, and we've already been over this too. But as the wine project progresses, severity levels will hopefully drop so that there will be more nuances. As Wine progress, the higher severities will be less and less. Higher sev levels will stand out a lot more. That's what they're for. I just think there is something severely when registering a bug that results in unworkable applications is considered a "normal" or even "minor" bug. To me, that's sending the wrong signals about the ambition of the project. Nobody else seems to have this problem. Unless the "not yet suitable for general use" from the faq is everywhere with blinking warning signs. Bares no relevance whatsoever to severity levels in Bugzilla. //Nicklas Note to self: Reply to ALL.
Re: Severity levels
IneedAname wrote: On Sun, 03 May 2009 18:10:03 +0100 Ken Sharp wrote: That would be the "Show Apps affected by this bug" link then. http://appdb.winehq.org/viewbugs.php?bug_id=16281 Thanks I missed that so how but my first point still stands. Not really. 16281 certainly isn't a major loss of functionality, no matter how many bugs are attached to it.
Re: Severity levels
Nicklas Börjesson wrote: How many times does this have to be repeated? Severity levels are NOT determined by how much a user wants the app to work. They're just not, deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). And you've already been told it shouldn't, and this has been explained to you. Junk.
Re: Severity levels
James Mckenzie wrote: One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. Yes, here: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
Re: can't find winedbg
Vitaliy Margolen wrote: Ben Klein wrote: 2009/5/5 Vitaliy Margolen : Mike Kaplinskiy wrote: executable, so you would run it like: ./wine ./programs/winedbg/winedbg.exe.so './wine winedbg' will do the same. Will that look-up in ./programs/winedbg before looking in $PREFIX/lib/wine/? Should. I don't have Wine installed (and never had) but winedbg, notepad, winecfg & all other programs work just fine. It seems to. ./wine is a wrapper, you should be able to open it in a text editor and have a look.
Re: Severity levels
Nicklas Börjesson wrote: No it isn't. It's an indication on how many people think they're more important than anyone else filing a bug. I think that you are wrong. Granted, some people do, they are called morons. But most people aren't morons. They are people, and to them, the issue really is critical. At least they think that. Give people the benefit of the doubt here. How many times does this have to be repeated? Severity levels are NOT determined by how much a user wants the app to work. They're just not, deal with it. It doesn't matter what the users think, we've been over this, it would be up to MS coders. They would put a high priority on it because Adobe it a major player, and I'm sure MS makes a lot of money out of them one way or another. This is a FOSS project and has no bearing on severity levels. So Photoshop has not been the least prioritized? What are you talking about? A lot of people use Photoshop, that's why it has been given more attention. This is FOSS software, the more popular an application is, the more people will be involved in getting it to work. Photoshop is very popular. "Acme Inc. Card Counter" is not. Photoshop has been prioritised because it is so popular, it is also affected by a LOT of bugs. This adds up to 1+1=2 and nothing more. Photoshop bugs are prioritised in exactly the same way all the other bugs are. I don't think you paint the entire picture. I don't think you can see the picture. If a set of devs decide to work on getting a particular app working that's up to them, and we've already been over this too. Obviously. I can't remember opposing that? Who said you had? Bares no relevance whatsoever to severity levels in Bugzilla. Nothing does, does it? Not to you, no. Only what you think is right. //Nicklas
Re: Severity levels
Henri Verbeet wrote: When you're not subscribed to the list, your posts have to go through moderation. Sometimes that can take a while. So the idiot isn't even subscribed to this group, but is spamming it anyway? Don't feed the trolls.
Re: Shuttleworth on Wine
If anyone has some simple applications that are easy to test (preferably, with no installer), shoot me an e-mail and I'll add it to my my list of applications to look at. Ha. That's a shame because Installshield is a real PITA. ;-)
Re: Shuttleworth on Wine
Austin English wrote: It's the registering/download manager that makes it not useful. It's much harder to script all of that. Is CS2 too old? http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2.exe
Updating bugs in Bugzilla
Hi all, Is there any way I can have access to update bugs that I did not open in Bugzilla? I update a lot of bugs and some of them are not set correctly (incorrect component or incorrect URL). Wrong URLs are a real pain because it can lead to testing the wrong version of an app (see Bug 13371). At the moment I have to ask someone with access to make these changes for me, and they're not always done. I don't want to ask them repeatedly because they have better things to do, I'm sure, and it would be easier if I could do it myself. I have admin access on the AppDB for this reason. Is there any way I could have a similar access on Bugzilla? I had no idea where to send this email to... Thanks, Ken.
Re: Updating bugs in Bugzilla
Done without reply. :-p Thanks. Ken Sharp wrote: Hi all, Is there any way I can have access to update bugs that I did not open in Bugzilla? I update a lot of bugs and some of them are not set correctly (incorrect component or incorrect URL). Wrong URLs are a real pain because it can lead to testing the wrong version of an app (see Bug 13371). At the moment I have to ask someone with access to make these changes for me, and they're not always done. I don't want to ask them repeatedly because they have better things to do, I'm sure, and it would be easier if I could do it myself. I have admin access on the AppDB for this reason. Is there any way I could have a similar access on Bugzilla? I had no idea where to send this email to... Thanks, Ken.
Changing default severity in Bugzilla to Normal
"It seems the default severity, enhancement, invites people to select a REALLY SEVERE sounding level instead. I suggest changing the default severity to normal in the hopes of cutting down on the yelling." http://bugs.winehq.org/show_bug.cgi?id=13363 Any thoughts on this?
Re: Regular users right on bugzilla
André Hentschel wrote: Jerome Leclanche schrieb: Since there's been some discussion about bugzilla recently... Is there any reason regular users aren't allowed to change keywords, component and dependencies on bugs they don't own on Bugzilla? Maybe marking as duplicate as well. I don't think it'd do any harm to allow those rights to every registered user. Cheers Jerome Maybe not to all users, there are always spammers, etc. But the idea is great, maybe we can give these rights just to the developers(everyone, who sent more than X patches). That makes more sense for me. Technical that means, every developer sends a mail somewhere with a keyword "bugzilla-mod" or something and the e-mail-adresses are compared with the registrations of wine-dev and wine-patches or with the commits in git. Most developers already have that access, and if they don't, they can just ask for it. I think the reason all users can't do it, is because most users don't know what they're doing. It's bad enough correcting all the mistakes they make now, the last thing we need is every user doing whatever they like whenever they like. Ask the poor triage guys who have to change nearly every bug.
Re: Regular users right on bugzilla
Top posting is the devil. Jerome Leclanche wrote: Fair enough for duplicates. Still, component and keywords can't do any harm, can they? I often see a bug with attached patch, or a regression, not properly marked as such, and want to fix it but I'm unable to; and it's usually not worth the extra spam and bothering someone else. I think you can send an email to wine-bugs asking for this to be changed? Or IRC, or -devel... there are many places to ask. The problem with keywords is people putting "fixme" in just because there's a fixme in the console output. It's rarely related. (Annoyingly, some people do the opposite to me) :P And "patch" doesn't mean there's a patch attached, it means there's been a patch sent and it's waiting for approval (according to the help section in Bugzilla). I foresee many issues with this proposal. It's also annoying getting, "I see this too when I press X and then blah and then this..." when the cause is already found, and when a user can just CC themselves or vote for a bug. The cause, fix or workaround ends up buried under a load of junk.
Add stable Wine versions back to the AppDB
See http://bugs.winehq.org/show_bug.cgi?id=15419
The AppDB is currently set up to query Bugzilla for its six latest Wine
versions. Unfortunately this does not include the latest stable version
of Wine (currently 1.0.1, and in the future 1.2 will also be omitted).
A change to how the AppDB works is needed to add 1.0.1 back to the list.
As 1.0.1 is listed as "stable", it would make sense that distros (Ubuntu
for example) will provide support for this version only.
As discussed in the bug, not having this version in the AppDB does not
stop users from submitting test results anyway using any version they
feel like selecting, and therefore reporting, often incorrectly (due to
regressions), that apps run fine on later versions of Wine.
As also discussed, if an Admin catches such test results in the queue
before they are accepted, they can be rejected, but maintainers can
submit whatever results they wish without admin approval. Test results
are rejected daily, so this is a problem.
Attached is a patch that hopefully looks something like what needs to be
added to the AppDB code. This was made by me, who has never used PHP
before and have given myself about an hour's "training" to figure it
out. It is probably wrong.
Could anybody offer some help with this issue?
Thanks,
Ken.
>From 5ae7aff9afeb66d0cce7cb0cb5043c01bef6e4a6 Mon Sep 17 00:00:00 2001
From: Ken Sharp
Date: Wed, 10 Jun 2009 11:58:49 +0100
Subject: [PATCH] Add 1.0.1 to the list of Wine versions.
---
include/util.php |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/util.php b/include/util.php
index bf6f8df..0c70401 100644
--- a/include/util.php
+++ b/include/util.php
@@ -179,6 +179,9 @@ function get_bugzilla_versions()
while(list($sValue) = query_fetch_row($hResult))
{
$aVersions[] = $sValue;
+ $aVersions = array_insert($aVersions,6,"1.0.1");
+ // when 1.2 is released:
+ // $aVersions = array_insert($aVersions,7,"1.2");
}
return $aVersions;
--
1.5.6.3
Re: Add stable Wine versions back to the AppDB
I doubt I could do that. As I said, what I know about PHP I could teach George Bush. I don't really have the time to figure it out right now. I'll happily look at it later, but it could be months from now! Unless someone else wants to? :) A quick-fix would do for now, but as you say, there's a better way. Ken. Alexander Nicolaysen Sørnes wrote: Thanks for working on this issue! We should probably add a mechanism that would require less maintainance, by declaring a set of stable branches that should be included in the version list, such as 1.0 and 1.2. Do you think you could do that? Alexander N. Sørnes
Default Bugzilla search does not show resolved bugs
From http://bugs.winehq.org/show_bug.cgi?id=18790 "The default search (the search box at the top of this page) does not include closed bugs (rightly so), but it also does not include resolved bugs. This leads to duplicates that could be avoided." "This is for admin to configure in Administration->Parameters->Query Defaults->defaultquery. Add to the front of it: bug_status=RESOLVED&" Anyone with admin access that can make this change? Thanks, Ken.
Re: [Bugzilla]: Refuse to accept comments with big number of logs / back traces
I must have missed this. This would be incredibly useful. Does this affect all users though? Anastasius Focht would probably go over these limits but his comments are helpful. Vitaliy Margolen wrote: Vitaliy Margolen wrote: The limits are: 20 lines for logs (fixme, trace, err, warn) 10 lines for back traces --- Bugzilla/Bug.pm |7 +++ template/en/default/global/user-error.html.tmpl |4 2 files changed, 11 insertions(+), 0 deletions(-) So who is the one to commit this? Alexandre? Jeremy? Vitaliy.
Re: [Bugzilla]: Refuse to accept comments with big number of logs / back traces
Nikolay Sivov wrote: What is the purpose of that change? To reduce mailed amount or what? To improve readability of reports? Log quotation are very useful sometimes and this blocking only makes things harder for people who knows what they're pasting. http://bugs.winehq.org/show_bug.cgi?id=5 On new bug page we already have a rather big stop sign, if it isn't enough could we just add permissions to some bugzilla guys to wipe comments with logs pasted or it's out of bugzilla functionality? Attachments can be deleted, can comments be deleted?
Duplicates page: Permission denied
Since the upgrade of Bugzilla, the duplicates page reports permission denied. http://bugs.winehq.org/duplicates.cgi Can anyone with the relevant access check the permissions? This is http://bugs.winehq.org/show_bug.cgi?id=18665
Re: Posting deletions on AppDB
Did you include the rest of the comments? Vitaliy Margolen wrote: I'm having a problem with these posts delition by Ken Sharp. I do not see anything wrong there. 'wine start file.msi' is _the_ correct way to "run" msi files (that's what happenes when you double click). Even if there was something wrong, removing post is a bad thing to do. Please just explain in replay why it's wrong. Or just ignore it. Vitaliy. --
Re: Posting deletions on AppDB
Exactly, the AppDB does not include child posts that have been deleted. The first deletion was my error, the second deletion was no error. I have removed literally thousands of old comments. There seems to be three of us working through what is literally tens of thousands of comments, there are bound to be mistakes. Feel free to help, rather than complain. Vitaliy Margolen wrote: What do you mean? There were only 2 of his posts that you removed. I've attached both e-mails AppDB sent. Vitaliy Ken Sharp wrote: Did you include the rest of the comments? Vitaliy Margolen wrote: I'm having a problem with these posts delition by Ken Sharp. I do not see anything wrong there. 'wine start file.msi' is _the_ correct way to "run" msi files (that's what happenes when you double click). Even if there was something wrong, removing post is a bad thing to do. Please just explain in replay why it's wrong. Or just ignore it. Vitaliy.
Re: Looking for a fast way to clean up AppDB comments
Ben Klein wrote: What I'd like to see is an option to delete an entire thread of comments (ideally from an arbitrary point in the thread) in one hit. Usually, the comments that follow a post are meaningless without that post. This is the default action (changed in the last few months). Or some button "Delete all comments older then one year" would be quite useful. This would probably cast the net too wide :) +1 See http://bugs.winehq.org/show_bug.cgi?id=18287
Re: RFC: Mac OSX should use existing Pictures/ Music/ Videos/ etc. directories - how exactly?
I think Linux has the same problem too. joerg-cyril.hoe...@t-systems.com wrote: Hi, http://bugs.winehq.org/show_bug.cgi?id=19028 winecfg on Mac OSX (10.5.6 and .7) does not link "My Videos" etc. to the equivalent directories on the Mac. Everything is linked to $HOME (or was it Desktop/?) instead. What a pity! Mac OSX uses directories named Documents/, Pictures/, Videos/, Music/ -- even in the German locale. The Finder GUI provides localized names. Unlike XDG/Gnome there are no crazy hacks at session begin to rename directories based on the session's locale. I don't know how earlier releases of Mac OSX behave, i.e. whether these directories have always been present. Does anyone know a reference? I located the relevant places that would need a patch: dlls/shell32/shellpath.c:_SHCreateSymbolicLinks and possibly dlls/shell32/xdg.c:XDG_UserDirLookup However, some design issues are unclear to me, hence prevent me from writing a patch: - In what order to add the Mac check? - When to check for a folder named "My Documents" (MS-Windows non-localized name in English locale, possibly translated), and when for "Documents" (MacOS constant name)? - Use XDG on the Mac or not? (if linked in, e.g. possibly when compiled via MacPorts, which pulls in a zillion libraries. Apple does not provide libfreedesktop.) Thanks for your comments, Jörg Höhle -- SSL Certificates from only £9.99 http://www.123-reg.co.uk/affiliate2.cgi?id=AF62286
Re: Removing active maintainers
There were 300 comments, all removed. I asked you to do this, between 15 maintainers, and you couldn't be bothered. That is why you were removed. Doing nothing is no help to anyone, as you have already been told, many times. Yet you're the only one complaining. Amazing. Vitaliy Margolen wrote: Why did someone removed active maintainers from most active applications? Do you guys even care who active who not? I was the only one doing _anything_ on Steam AppDB entry. And I was removed by Ken Sharp because he didn't like 9 "oldish" posts??? WTH? This got to stop! If someone doesn't like old entries - well that's just too bad. Don't go to those apps, or fix AppDB to split comments into several pages. I'm appreciate what Ken was doing but not anymore. Please remove him from the admin role an AppDB. This is way over the head of what he's been doing. Vitaliy.
Re: Removing active maintainers
Rosanne DiMesio wrote: If there has been a recent discussion amongst the admins as to when it is appropriate to remove maintainers, I was left out of it. The only official policy I know of is tied to the failure to process test reports within a week, and the automatic mechanism for doing that isn't even working at the moment. If maintainers are to be removed for other reasons, I think the admins need to come to a consensus about when, why, and how this should be done. Agreed, but in this case it is a moot point. The particular application, Steam, often has test results waiting for > 8 days, so all FIFTEEN idle maintainers would have been removed long before I had to do it manually, had the automatic deletion mechanism been working. This is true of all maintainers we have been removing. More need to be removed as the test results in the queue are well over this 8 day threshold. To give a scale of the problem: There are approx. 7700 program in the appdb. There are approx 21,730 comments going back to 2004. If it's not the maintainer's job to make sure the comments aren't tidied up, whose is it? I'm not the only admin cleaning up comments.
Re: Removing active maintainers
Ricardo Filipe wrote: on this particular case i feel ken and vitaly should have communicated more to understand each others points of view and reach a consensus. although i can totally see why ken decided to remove him from maintainer this should not be done lightly. Ken asked Vitaliy to do this twice. His "consensus" was to remove all the other maintainers and leave him as the only one.
Re: Removing active maintainers
Henri Verbeet wrote: 2009/6/25 Ken Sharp : To give a scale of the problem: There are approx. 7700 program in the appdb. There are approx 21,730 comments going back to 2004. If it's not the maintainer's job to make sure the comments aren't tidied up, whose is it? I'm not the only admin cleaning up comments. It's not entirely clear to me why old comments need to be deleted. What use is 300 comments in appdb entry?
Re: Removing active maintainers
Niklas Hambüchen wrote: Sjors Gielen wrote: If you meant, why should they be deleted instead of kept for reference; there could be an archive, but currently they are deleted, afaik. Why don't you just save an outdated: true/false information? Those posts could just be not displayed by default, but if someone ever needs one of those, he could just click the magical "Show all"-button. And for the admins/maintainers just a per post "mark outdated"/"mark relevant" link. Because the AppDB isn't supposed to be a forum. I can see no useful reason for keeping old comments, and "Same here" comments are plain useless, but are left anyway. I would also like to point out that comments being deleted has been standard since long before I'd even heard of Wine. Few maintainers do this themselves, but it's usually left up to admin to do it. Nobody said anything when I raised this: http://bugs.winehq.org/show_bug.cgi?id=18287 Probably because it is the obvious resolution to old and useless comments - delete them.
Re: Removing active maintainers
Vitaliy Margolen wrote: Ken Sharp wrote: Agreed, but in this case it is a moot point. The particular application, Steam, often has test results waiting for > 8 days, so all FIFTEEN idle maintainers would have been removed long before I had to do it manually, had the automatic deletion mechanism been working. That's why I told you to remove all of them, except me. Since I was the only one doing anything there. And yes I do have my own life too and can not immediately approve all test results. Vitaliy. Hardly, you spend most days arguing on Bugzilla, where comments can not be removed, so stop trying to play the victim. Notice, you're the only one complaining, out of all the maintainers that have been removed over the past few weeks.
Re: Removing active maintainers
Vitaliy Margolen wrote: Ken Sharp wrote: Because the AppDB isn't supposed to be a forum. Who said that? It was _the_ only "official forum" long before forum.winehq.org came to be. I can see no useful reason for keeping old comments I can name several reasons: 1. Apps that don't change much and old problems still exit (years later) 2. Historical records of what got eventually fixed or worked around. Useful if anyone wants to test old Wine version. Or do the same bad things. 3. Problems that still apply to lots of other applications. Or all games run under Steam. 4. Lots of new problems are well forgotten old problems. 5. Knowledge never gets old. What are the reasons to remove old comments, other then being too slow to refresh page? You've just described what notes are for. I would also like to point out that comments being deleted has been standard since long before I'd even heard of Wine. I've only heard of few such cases, mostly with hot games like WoW or programs like IE. Former had too much noise and same problems over and over again. Later had too much of invalid / obsolete information. Neither is the case with Steam. Nobody said anything when I raised this: http://bugs.winehq.org/show_bug.cgi?id=18287 All the bug talks about is how painful it is to remove comments. Now why they should be removed, where that information is published for _everyone_ to see, comment, discuss. Because it's bloody obvious or THEY WOULDN'T BE REMOVED LONG BEFORE I STARTED DOING IT. Vitaliy
Re: Removing active maintainers
John Klehm wrote: No doubt it's a good thing to keep the appdb information up to date and clean out inactive accounts. However it seems that if someone wants to do the work why should we have a policy to prevent them from participating according to the time their life allots? Last I checked we werent over staffed quite yet. Especially when there isn't a maintainer at all now for this app? http://appdb.winehq.org/objectManager.php?sClass=version&iId=1554 --John Klehm Like I've already said, the whiner, Vitaliy, will have been removed LONG BEFORE I removed him by automatic deletion, so all his points are moot.
Re: Removing active maintainers
Vitaliy Margolen wrote: Ken Sharp wrote: There were 300 comments, all removed. Say what? I got only 9 messages of removed comments. That's because you still don't understand how the emails are sent. We went through this last time you had a rant and nobody took any notice because you're known for it. Between all the apps you maintain, and there aren't enough to justify it, there are over 500 useless comments. As a user, how is that helpful? Your rants bore me now. Keep it though, it just validates my point.
Re: Removing active maintainers
Tom Wickline wrote: On Thu, Jun 25, 2009 at 8:51 PM, Vitaliy Margolen mailto:wine-de...@kievinfo.com>> wrote: I'm still asking to remove Ken Sharp from AppDB admins. This behavior is totally unacceptable. Removing user comments just because Ken doesn't like them is not a valid reason. +1 I'm asking to remove Vitaliy from all maintainership. He spends most of his time arguing on Bugzilla and can't be bothered to maintain the few apps he's supposed to be maintaining. 1. Maintainers are removed every day for being idle. 2. This is automatic when the script works and Vitaliy WOULD HAVE BEEN REMOVED AUTOMATICALLY LONG BEFORE NOW, and therefore would be complaining about someone else. 3. Between the few admins on the AppDB, comments are removed whenever there is chance too. 4. This is what a well-maintained app looks like: http://appdb.winehq.org/objectManager.php?sClass=version&iId=3754 Notice the lack of nonsense and useful information being moved into notes. Tom Wickline Of course this guy agrees, he's been removed for being idle!
Re: Removing active maintainers
Austin English wrote: On Thu, Jun 25, 2009 at 8:06 PM, Vitaliy Margolen wrote: Ken Sharp wrote: Because it's bloody obvious or THEY [comments] WOULDN'T BE REMOVED LONG BEFORE I STARTED DOING IT. I've never seen anything on wine-devel / wine-forum / winehq.org front page / wiki about removing old comments until one day I got 100 or so notifications of comments removed by you. And message threatening to remove all maintainers if they don't remove old comments themselves... I wouldn't call this an official means of communications and discussing wholesale changes. If you think that old comments must be removed, you should ask first interested parties on at least wine-devel if there are any objections/comments/etc. You failed to do so. Everyone, let's calm down please. We're all adults here (or so I hope...). As far as 'official guidelines', there is: http://appdb.winehq.org/help/?sTopic=maintainer_guidelines but it doesn't have any timelines/etc. Perhaps we should focus energy on that instead of arguing on bugzilla. The scripts remove idle maintainers after eight days. Vitaliy, along with many others, would have been removed long before now if they had been working. Instead, maintainers get the names of the admin removing them, and then "they" complain about that person directly. Let me say this, yet again, maintainers would have been removed long before now had the scripts been running correctly. Alexander added that he will email Jeremy (sorry, I don't know who you are) to check why the scripts aren't running. I will add this again. Vitaliy, along with others, will have been removed automatically long before now. The problem here is with the script, but there is a bug open for that. http://bugs.winehq.org/show_bug.cgi?id=18947
Re: Removing active maintainers
Remco wrote: I maintain two apps. I haven't updated their status in months. Yet, I'm not removed. Apparently, this is because no other people added something to these pages either. The problem, as I see it, is with the job of maintainer. It's really two jobs in one: you're a moderator of user contributions, and you're the page editor. Now, I don't really care about user contributions. I'll confirm them when they get in my inbox, but it's not why I become a maintainer of an app. The only reason I became a maintainer for those two apps, is because I wanted to add notes and howtos. Maybe that could be governed more like a wiki: anyone (who's logged in) can change the page, and every edit is listed in a changelog. Just like with wikis, you can 'watch' pages for changes, which is sort of analogous to becoming a maintainer. The comments would then be analogous to a wiki talk page. Remco I think the popular apps have their own Wiki page (or they were created but not maintained). http://wiki.winehq.org/AdobePhotoshop for example. If the HOWTOs are particularly complicated for an app, it would make sense to host a Wiki page.
Re: Removing active maintainers
Alexander Nicolaysen Sørnes wrote: It's important to note that the script would also have warned maintainers that there are queued items for the apps they maintain. Yup, but queued data is also listed down the left of the page, and an email is sent to the maintainer for every test result, bug link, screenshot and comment added to the app (as well as monitor and other stuff, but that's another issue...) We can make it so only the first 25 threads are shown by default, then have a 'show all comments' link. This should make it easier for users, maintainers and admins alike. Is 25 a good limit? Please post your suggestions. It doesn't really matter how many comments are shown, most of them are useless, and if clicking on "Show all" shows hundreds or thousands of comments, the user is still none-the-wiser. It would certainly look a lot nicer though. There are a few pages that create long lists that need tidying up, but I don't think they affect users or maintainers. Alexander
Re: Removing active maintainers
Remco wrote: Yes, I should have been more clear that the test data would be different from the wiki-like sections of the page, and still be accepted by admins/maintainers. The only thing I would like to see as a wiki, is the rest of the page: descriptions, screenshots, notes. But the test data can also get some wiki-like qualities: accepted by default, but then added to a list of new test data, so that people who care can remove long terminal output, correct the rating, or delete the test data altogether. That is a really good idea, but would it be too difficult to implement? Still a very good idea though.
Re: Removing active maintainers
Dan Kegel wrote: 3. Eight days is way too quick to remove an inactive maintainer. Six months is more like it. That is far too long. After two weeks there are 100 test results waiting in the queue. Six months wouldn't help the users out at all. Their test results would disappear into a black hole.
Re: Appdb flight simulation sub category
Simulation Games is already in there. Besides, I don't think the categories are actually all that useful. Keith Muir wrote: Hi, Any chance of a games> simulation> flight simulation sub category? Regards, Keith
Translations/locale
Can someone tell me what's going on on this page http://source.winehq.org/transl/lang.php?lang=009%3A00 ? If you click on the bottom links (locales) I see a message "Invalid resource file". Does this mean the resource file doesn't exist, or is there a little oops in the links? Thanks, Ken.
Re: which release of Wine created or last updated this particular .wine/ tree?
Is anything dropped into the registry? joerg-cyril.hoe...@t-systems.com wrote: Hi, my HD contains a dozen .wine*/ directories created with various settings and releases of Wine, some a long time ago. A repeating question is: With what release of Wine did I create this particular .wine/ tree ? Or rather: what release last updated this .wine/ tree? It is not acceptable to run ~/src/most-current-wine/winecfg "about" on this .wine/ tree since an update that would change the bug footprint, causing the tested apps to work differently. At the time of ~0.9.60, the answer was easy because tools/wine.inf was copied into .wine/drive_c/windows/inf/wine.inf and contained a release number. Another possibility would be that I build a mini-DB of e.g. drive_c/windows/notepad's md5. Not very reliable, as notepad.exe need not change with every release. Any other ideas? Jörg Höhle.
Re: Wineboot crashes after upgrading Gecko.
Nikolay Sivov wrote: Hi. After upgrading to Wine-gecko 1.0.0 I've got a wineboot crashes on initial .wine directory creation (log attached). Removing cab throws a message about missed gecko engine and no crash occurred. What is it about? Same here, thought it was just me.
Re: Appdatabase racing and flightsim category
Sorry, I missed this... but, I was busy anyway. Alexander Nicolaysen Sørnes wrote: Tirsdag 28. juli 2009 22.39.32 skrev Keith Muir: I submitted a list of flight sims for this category to Ken Sharp I notice the category has been updated with racing games but not flight anyone know what he did with my list Regards, Keith I have updated the categories now. Thanks for the list! Alexander N. Sørnes
Re: Latency as of yesterday
Susan Cragin wrote: I got a new kernel and a new git yesterday. One of them is causing massive latency in my sound system. I looked at the changes to git that were made yesterday, and suspect that the latency came with the kernel. 2.6.31-5-generic is the new kernel. Just for "fun" I reinstalled my entire system this morning, and the latency is the same, so it is not due to any tweaks I have made. I have been running using winecfg's oss sound and padsp for a week or so. It had been working fairly well. Anyway, before I file a bug on Ubuntu against the kernel, I thought I would ask if yesterday's git might be at fault. I don't have time to do regression testing before Friday, but I will do it if needed. Susan Ubuntu has bugs open for sound issues with the newer kernels. (Separate issue -- I have not been able to run dragon NaturallySpeaking with alsa for several months. Timeout issues during training.) Is there a bug logged for this?
Re: dotnet30 and winetricks
Dan Kegel wrote: Thanks to AF and Hans (and Codeweavers), there's now a short recipe for installing .net 30. I've added it to winetricks. Give it a shot and let me know if it works for you... Installs nice here, but don't have anything to test it against at the moment. Just curious, why does the script switch back to the old Gecko? Executing cabextract -q /home/test/.winetrickscache/wine_gecko-0.9.1.cab Executing wine regedit /home/test/.wine/drive_c/winetrickstmp/geckopath.reg Or is it just to make sure that a Gecko is installed?
Re: AppDB isn't working
Igor Tarasov wrote: AppDB displays only decorations and navigation - no content on all pages. Maybe this is due to recent commits? It works fine here.
Re: submitted AppDB links to bugzilla not working anymore?
joerg-cyril.hoe...@t-systems.com wrote: Hi, Several recent link proposals between AppDB and Buzilla acknowledged by "The bug link you submitted between Bug NNN and XYZ has been accepted." have nevertheless produced no visible bug # in AppDB nor "Show Apps affected" in Bugzilla. E.g. Bug #19773 among others. Did some recent changes to the server break that functionality? Just tested and works fine here, please try again (Bug #1 would be a reasonable "test" bug). Remember you need to be a maintainer of an application for the bug to be added immediately, otherwise it remains in a queue for a maintainer or admin to accept/reject it. Of course, you should receive an email either way unless you have them disabled. BTW, a few month ago, I was pleased to see that some links were automatically(?) created when the bug subject had the format app-name: blabla That was a useful idea! This was never implemented afaik. It is likely that admins added the link themselves, as most users can not be bothered.
Re: submitted AppDB links to bugzilla not working anymore?
André Hentschel wrote: i had this problem too. i submitted it, it was accepted, and then it wasnt shown. OK, just tried with a different account and can confirm this. http://bugs.winehq.org/show_bug.cgi?id=19857 It's a bit odder than I'd hoped.
Add jscript component to Bugzilla?
Any chance someone could add a jscript component to Bugzilla? It's used a decent amount to warrant it...
Re: Add jscript component to Bugzilla?
Ken Sharp wrote: Any chance someone could add a jscript component to Bugzilla? It's used a decent amount to warrant it... Nobody bothered?
Re: Usual oss choices missing in winecfg, in today's git
Susan Cragin wrote: Just built today's git, and am running DNS with alsa. (Thanks, Maarten.) Called up winecfg as usual and found there were no options under OSS Driver. No wave-out, no wave-in, no mixer devices. Nada. Peculiar, never saw this before. So I thought I'd call in. Have you performed a regression test?
Re: avifil32: Update English resource
On 15/06/10 09:00, Alexandre Julliard wrote: Ken Sharp writes: @@ -50,3 +51,43 @@ STRINGTABLE DISCARDABLE IDS_AVIFILETYPE "Wine AVI-default-filehandler" IDS_UNCOMPRESSED "uncompressed" } + +LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL +/* Same as SUBLANG_DEFAULT */ If they are the same there's no reason to duplicate them. Also you should never submit 60 patches in one go; 10-15 is the maximum for a patch series, and that's only if you are absolutely confident that they are correct. Otherwise send only a couple until you are sure to get it right on the first try. It will set the statistics to 100% for all the English languages: they're currently at 7%. http://source.winehq.org/transl/ 100% seems to be what other FOSS projects are aiming for. There is no way to say SUBLANG_NEUTRAL = SUBLANG_DEFAULT at the moment.
Re: avifil32: Update English resource
On 15/06/10 10:28, Michael Stefaniuc wrote: That's just an artifact of how the translation statistics tool works. But Wine will use LANG_ENGLISH SUBLANG_DEFAULT if there is no SUBLANG_NEUTRAL translation. Duplicating unneeded resources makes them prone for bitrotting. bye michael I was told that US English = Default and British English = Neutral, and that all the other English sublangs pick up Neutral except en_US. So, are you saying what actually happens is that it first looks for NEUTRAL, and if it doesn't find that it looks for DEFAULT? And that NEUTRAL should be British English? If so, why is there a DEFAULT at all? I wondered why there was also a ENGLISH_US in kernel32/nls. If it actually looks for NEUTRAL first it would save a lot of duplication and would make the translations easier. Hope that makes sense.
Re: avifil32: Update English resource
On 15/06/10 20:34, André Hentschel wrote: BTW: Placing your Copyrights in the translation files for some text copying is somehow naughty... I asked about that in #winehackers and I was told I should add my own copyright. Personally, I couldn't care less.
Re: avifil32: Update English resource
On 15/06/10 20:26, Michael Stefaniuc wrote: On 06/15/2010 08:53 PM, Ken Sharp wrote: On 15/06/10 10:28, Michael Stefaniuc wrote: That's just an artifact of how the translation statistics tool works. But Wine will use LANG_ENGLISH SUBLANG_DEFAULT if there is no SUBLANG_NEUTRAL translation. Duplicating unneeded resources makes them prone for bitrotting. I was told that US English = Default and British English = Neutral, and that all the other English sublangs pick up Neutral except en_US. So, are you saying what actually happens is that it first looks for NEUTRAL, and if it doesn't find that it looks for DEFAULT? And that NEUTRAL should be British English? If so, why is there a DEFAULT at all? I was saying that LANG_ENGLISH SUBLANG_DEFAULT is special aka the ultimate fallback for *all* other languages. So if a resource isn't available in a language (neither in the country specific sublang nor in the neutral sublang) it will eventually fall back to LANG_ENGLISH SUBLANG_DEFAULT. That includes also the other English sublangs; thus there is no point in duplicating the LANG_ENGLISH SUBLANG_DEFAULT resources in LANG_ENGLISH SUBLANG_NEUTRAL as the result is the exact same, achieved with less code. OK, that makes sense. If no resources for that LANG/SUBLANG is available it falls back to LANG_ENGLISH SUBLANG_DEFAULT.. that's fine. And so it's safe to say that SUBLANG_DEFAULT is US English (the translation page says it is) and the other sublangs pick up SUBLANG_NEUTRAL (I don't know where this is defined but testing the patches agrees with what the translation stats page says). So, the only time SUBLANG_NEUTRAL needs to be added is if the language varies from US English (such as colour, favour, minimise, etc.). ENGLISH_CAN then picks up NEUTRAL but sometimes the language varies again, so that needs to be added to correct that. Also, ENGLISH_PHILIPPINES always uses US English, so should pick up DEFAULT by default to reduce the amount of translation required (Bug 23124). And of course if there are any other sublangs that differ from the NEUTRAL they should be added too (most follow the same rules so this will probably never be necessary). This is how I originally did it but I got phased my the translation stats. I'll do a couple of small patches later to see if I can get it right this time! I've got a couple of Welsh and Gaelic patches too, but they are very small. I wondered why there was also a ENGLISH_US in kernel32/nls. The NLS files are not really a translation, they are the "localization" part even though they do contain some translations. If it actually looks for NEUTRAL first it would save a lot of duplication and would make the translations easier. Hope that makes sense. Not really. Please have a look at http://wiki.winehq.org/SublangNeutral it describes how the fallback works in Windows. Why they did it that way you probably have to ask them; Wine just has to follow it. I read all that before but it didn't make any sense until now. Thanks for clarifying. bye michael So whoever accepts or rejects the patches, you may as well reject all of mine (if you haven't already). I'll send them again once I'm on the right track. Thanks all.
RE: comctl32: Update English resource
: -Original Message- : From: Juan Lang [mailto:juan.l...@gmail.com] : Sent: Wednesday, 16 June 2010 6:41 PM : To: Ken Sharp : Cc: Wine Devel : Subject: Re: comctl32: Update English resource : : Hi Ken, : : +LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_CAN : + : +IDD_TBCUSTOMIZE DIALOG DISCARDABLE 10, 20, 357, 125 : +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU : +CAPTION "Customize Toolbar" : +FONT 8, "MS Shell Dlg" : +BEGIN : + DEFPUSHBUTTON "&Close", IDCANCEL,308,6,44,14 : + PUSHBUTTON"R&eset", IDC_RESET_BTN,308,23,44,14 : + PUSHBUTTON"&Help", IDC_HELP_BTN,308,40,44,14 : + PUSHBUTTON"Move &Up", IDC_MOVEUP_BTN,308,74,44,14 : + PUSHBUTTON"Move &Down", IDC_MOVEDN_BTN,308,91,44,14 : + LTEXT "A&vailable buttons:", -1,4,5,84,10 : + LISTBOX IDC_AVAILBTN_LBOX,4,17,120,100, LBS_NOTIFY | : LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | : LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP : + PUSHBUTTON"&Add ->",IDOK, 131, 42, 44, 14 : + PUSHBUTTON"<- &Remove", IDC_REMOVE_BTN,131,62,44,14 : + LTEXT "&Toolbar buttons:", -1,182,5,78,10 : + LISTBOX IDC_TOOLBARBTN_LBOX, 182,17,120,100,LBS_NOTIFY | : LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | : LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP : +END : : I don't understand why you would want to create multiple : "translations" when their content is identical. If it's because the : statistics you're generating claim a particular variant of English is : incomplete, then you should fix the tool you're using to generate the : statistics: unless there's an actual difference between American : English and the variant, there's no need for a translation. : --Juan SUBLANG_ENGLISH_CAN picks up SUBLANG_NEUTRAL not SUBLANG_DEFAULT, and the spellings are different.
RE: comctl32: Update English resource
: -Original Message- : From: Alexandre Julliard [mailto:julli...@winehq.org] : Sent: Wednesday, 16 June 2010 7:10 PM : To: Juan Lang : Cc: Ken Sharp; Wine Devel : Subject: Re: comctl32: Update English resource : : Juan Lang writes: : : > I don't understand why you would want to create multiple : > "translations" when their content is identical. If it's because the : > statistics you're generating claim a particular variant of English is : > incomplete, then you should fix the tool you're using to generate the : > statistics: unless there's an actual difference between American : > English and the variant, there's no need for a translation. : : The title is different, but I don't think that such minor spelling : differences justify having 4 copies of every resource. I'd suggest : waiting for po files support. But isn't that the point of SUBLANGs in the first place? All SUBLANGs will have minor differences. I was also told no translation would be wasted. Minor or not, spelling things correctly would be nice. People over here can't spell as it is. How soon are we going to see PO file support? PO files are definitely easier and smaller, and nicer. : : -- : Alexandre Julliard : julli...@winehq.org
Re: mapi32: Add Gaelic resource (try2)
On 6/7/2010 7:30 AM, Paul Vriens wrote: On 07/05/2010 07:38 PM, Ken Sharp wrote: Hi Ken, Next to fixing the apply failure you should also add the "#pragma code_page(65001)" statement to avoid these warnings: Warning: string "R-phost a sheoladh mar a theip ní gá duit a cliant ríomhphoist MAPI shuiteáil." seems to be UTF-8 but codepage 1252 is in use. Warning: string "Seol Ríomhphost" seems to be UTF-8 but codepage 1252 is in use. Hi Paul, I don't know what's going on. My git is up-to-date according to git and the patch applies fine here. I've also had issues with the bloody stupid editor and code pages. Thanks, I'll have another look.
Re: sane.ds: Add Welsh resource
On 6/7/2010 9:55 AM, Huw Davies wrote:
On Mon, Jul 05, 2010 at 06:51:36PM +0100, Ken Sharp wrote:
+{
+ 0 ""
+ 1 "px"
+ 2 "b" /* What is "b" ? */
+ 3 "mm"
+ 4 "dpi" /* dotiau fesul modfedd */
+ 5 "%"
+ 6 "ns" /* What is "ns" ? */
+}
See the SANE_UNIT_ defines in /usr/include/sane/sane.h
'b' is bits and 'ns' should be microseconds, so it looks like the
English resource is incorrect too.
Huw.
PS Happy to see the Welsh translations coming in!
I was wondering if it was supposed to be microseconds but I wasn't sure!
It looks as if DPI is used in Welsh too (as it's just an acronym after all).
I thought I'd add the British languages - British English has been
rejected as too much code (despite the fact this is the language of the
UN), but if I gave a quick start to the other languages I was hoping
someone might take over. :)
Doesn't look like any of the Scottish languages is covered though. :(
I shall update and resubmit, thanks.
kernel32: Update Welsh resource
Could someone take a look at this for me? http://source.winehq.org/patches/data/63232 It applies fine here but http://source.winehq.org/patches/ says it fails. I can't see what's wrong. :( Thanks.
Re: mapi32: Add Gaelic resource (try4)
On 6/7/2010 9:51 PM, Paul Vriens wrote: On 07/06/2010 08:45 PM, Ken Sharp wrote: Works fine here, but I've changed the encoding of the patch to see if that helps. Hi Ken, This one is even worse: ../../../wine-git/dlls/mapi32/Ga.rc:32:87: Error: Invalid character in string 'R-phost a sheoladh mar a theip n� g� duit a cliant r�omhphoist MAPI shuite�il.' for codepage 65001 make[1]: *** [Ga.res] Error 1 make[1]: Leaving directory `/wine/wine64/dlls/mapi32' make: *** [dlls/mapi32] Error 2 You've changed the encoding of the file but left in the pragma. The problem with applying was not with Ga.rc but with the changes to Makefile.in Ah I see. Works fine here so something must be broke. :(
Re: sane.ds: Change "ns" to "ms" in resource files
On 7/7/2010 10:30 AM, Alexandre Julliard wrote: Ken Sharp writes: Apparently the English resource file should show "ms" (microseconds) instead of "ns". This error has been copied too all the .rc files. "ms" doesn't mean microseconds. What does it mean? I couldn't find a definition.
Re: mapi32: Add Gaelic resource (try4)
On 7/7/2010 10:34 AM, GOUJON Alexandre wrote: On 07/06/2010 11:51 PM, Michael Stefaniuc wrote: Did you test it with a fresh branch? You don't even need a named branch for that; one with the detached HEAD works as well for the test: - git checkout origin/master - git am $email I'm not an expert but here is what I do in these cases: git reset --hard origin #remove any change git status #to see if you have a clean directory, if not rm or mv all you want git pull #update git apply /path/to/your.patch You should also have a look at http://wiki.winehq.org/GitWine (^D it, very useful) I usually just use git fetch ; git rebase origin Followed by patch -p1 < foo.patch Never had any problems until recently.
Re: sane.ds: Change "ns" to "ms" in resource files
On 7/7/2010 11:39 AM, Huw Davies wrote: On Wed, Jul 07, 2010 at 11:28:21AM +0100, Ken Sharp wrote: On 7/7/2010 10:30 AM, Alexandre Julliard wrote: Ken Sharp writes: Apparently the English resource file should show "ms" (microseconds) instead of "ns". This error has been copied too all the .rc files. "ms" doesn't mean microseconds. What does it mean? I couldn't find a definition. http://en.wikipedia.org/wiki/Millisecond For microsecond you want 'µs' or failing that, 'us'. Well, yes, but that's what I was told. If it should be ms then the patch is ok. I don't understand what seconds are doing in a scanning "DLL" anyway, I don't ever recall it being used.
Re: sane.ds: Change "ns" to "ms" in resource files
On 7/7/2010 11:56 AM, Huw Davies wrote: On Wed, Jul 07, 2010 at 11:45:59AM +0100, Ken Sharp wrote: On 7/7/2010 11:39 AM, Huw Davies wrote: On Wed, Jul 07, 2010 at 11:28:21AM +0100, Ken Sharp wrote: On 7/7/2010 10:30 AM, Alexandre Julliard wrote: Ken Sharpwrites: Apparently the English resource file should show "ms" (microseconds) instead of "ns". This error has been copied too all the .rc files. "ms" doesn't mean microseconds. What does it mean? I couldn't find a definition. http://en.wikipedia.org/wiki/Millisecond For microsecond you want 'µs' or failing that, 'us'. Well, yes, but that's what I was told. If it should be ms then the patch is ok. I don't understand what seconds are doing in a scanning "DLL" anyway, I don't ever recall it being used. Huh? I told you yesterday that the string should be micro seconds, that's 'µs' and not 'ms'. Ah, I thought you meant milli. Ok, fair enough, can be changed easy enough. Thanks again.
shell32: Increase dde_connect res value
Evening all, http://bugs.winehq.org/show_bug.cgi?id=26830 is easily solved by http://bugs.winehq.org/attachment.cgi?id=34184 but I don't know if this will break anything. I cannot find a reference as to why it needs to be set to 256, but there must be a reason for this. Anyone any ideas? Thanks, Ken
Re: Another major milestone
On 19/07/13 15:00, Rosanne DiMesio wrote: On Thu, 18 Jul 2013 16:55:42 -0500 Jeremy White wrote: 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. What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. http://bugs.winehq.org/show_bug.cgi?id=24611 was added two days ago. *shrugs*
Re: appwiz: Correct Wine Mono installer messages
On 22/07/13 18:37, Alexandre Julliard wrote: Ken Sharp writes: Where the correction is obvious I have done so, but where a full translation is needed I have simply removed the incorrect one. This will mark that line as untranslated and hopefully someone will see that. It will also default to English with the correct message until translated. That's what fuzzy is for, there's no reason to remove them. Okay but at the moment, in those languages, a user is currently being told Gecko needs to be installed, followed by Gecko needs to be installed. I'll send a smaller patch correcting the title. Someone else can fix the long message. It should flag someone's attention the two being unequal. It has been this way for at least a year: nobody seems to be taking any notice.
Re: appwiz: Correct Wine Mono installer messages
On 22/07/13 19:39, Vincent Povirk wrote: Okay but at the moment, in those languages, a user is currently being told Gecko needs to be installed, followed by Gecko needs to be installed. Are you sure this isn't caused by needing 32-bit and 64-bit builds of Gecko? Certain. It's a translation error. http://source.winehq.org/patches/data/97455
Re: [PATCH 2/2] include/ddk: add usbioctl.h
On 22/07/13 19:57, Damjan Jovanovic wrote: On Mon, Jul 22, 2013 at 6:46 PM, Nikolay Sivov wrote: On 7/22/2013 22:38, Damjan Jovanovic wrote: Changelog: * add usbioctl.h Damjan Jovanovic Hi, Damjan. You forgot patches. I didn't. Why aren't they showing up? I've sent four patches. Three are showing.
Re: po: Update English (US) resource
Fair enough. I'll send an updated patch after the next bunch of commits. Please disregard this patch. On 24/07/13 16:12, Francois Gouget wrote: On Mon, 22 Jul 2013, Ken Sharp wrote: Logon/Log on as with the British/neutral patch. msgid "Can't logon with inter-domain trust account.\n" -msgstr "Can't logon with inter-domain trust account.\n" +msgstr "Can't log on with inter-domain trust account.\n" [...] I think these fixes should really be applied to the source winerror.mc file instead. If I remember correctly en_US.po is just a dummy translation where msgid and msgstr strings should be identical (there might (with maybe one or two exceptions for things like um -> µm).
kernel32: Correct log on / logon (noun / verb)
Evening Winos, Attached is a patch to correct some winerr messages. Specifically change a noun to a verb, and update the .po files with it. Firstly, could you take a look and point out any obvious errors I may have made? I have marked some of the translations fuzzy because it's not clear if the original translator realised that this should have been the verb and not the noun. A quick look through the translations on Wikipedia suggests that most languages do use different terms for the noun and the verb. https://cs.wikipedia.org/wiki/Login https://de.wikipedia.org/wiki/Login_(Informationstechnik) https://es.wikipedia.org/wiki/Login and so on. Some of these listings seem to use completely different words to the current translation in Wine so I wouldn't dare make a guess. Secondly, what do people think about the use of "Can't" as opposed to "Cannot"? I have not made the change in the patch but I'm wondering if people think that this should be done. Can't is informal and as my old English teacher would say, "Can't is not a word!" It is, but being pedantic "cannot" is probably the better choice. I assume Windows uses "can't" seen as it listed in winerror.mc. Thanks all! Ken From 180b6911bbc996df993f3e94f8d9c34da621cfad Mon Sep 17 00:00:00 2001 From: Ken Sharp Date: Thu, 25 Jul 2013 00:17:15 +0100 Subject: kernel32: Correct logon / log on (noun / verb) --- dlls/kernel32/winerror.mc |6 +++--- po/ar.po |9 ++--- po/bg.po |6 +++--- po/ca.po | 15 --- po/cs.po |6 +++--- po/da.po |9 ++--- po/de.po |9 ++--- po/el.po |6 +++--- po/en.po |6 +++--- po/en_US.po | 12 ++-- po/eo.po |6 +++--- po/es.po | 12 +++- po/fa.po |6 +++--- po/fi.po |9 ++--- po/fr.po | 12 +++- po/he.po |6 +++--- po/hi.po |6 +++--- po/hr.po |6 +++--- po/hu.po |9 ++--- po/it.po |9 ++--- po/ja.po |9 ++--- po/ko.po |9 ++--- po/lt.po |9 ++--- po/ml.po |6 +++--- po/nb_NO.po |9 ++--- po/nl.po |9 ++--- po/or.po |6 +++--- po/pa.po |6 +++--- po/pl.po |9 ++--- po/pt_BR.po |9 ++--- po/pt_PT.po |9 ++--- po/rm.po |6 +++--- po/ro.po |6 +++--- po/ru.po | 12 +++- po/sk.po |6 +++--- po/sl.po |9 ++--- po/sr...@cyrillic.po |6 +++--- po/sr...@latin.po |6 +++--- po/sv.po |6 +++--- po/te.po |6 +++--- po/th.po |6 +++--- po/tr.po |6 +++--- po/uk.po |6 +++--- po/wa.po |6 +++--- po/wine.pot |6 +++--- po/zh_CN.po |6 +++--- po/zh_TW.po |9 ++--- 47 files changed, 209 insertions(+), 154 deletions(-) diff --git a/dlls/kernel32/winerror.mc b/dlls/kernel32/winerror.mc index b96831c..b302e8c 100644 --- a/dlls/kernel32/winerror.mc +++ b/dlls/kernel32/winerror.mc @@ -3441,17 +3441,17 @@ No more bindings. MessageId=1807 SymbolicName=ERROR_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT Language=ENU -Can't logon with inter-domain trust account. +Can't log on with inter-domain trust account. . MessageId=1808 SymbolicName=ERROR_NOLOGON_WORKSTATION_TRUST_ACCOUNT Language=ENU -Can't logon with workstation trust account. +Can't log on with workstation trust account. . MessageId=1809 SymbolicName=ERROR_NOLOGON_SERVER_TRUST_ACCOUNT Language=ENU -Can't logon with server trust account. +Can't log on with server trust account. . MessageId=1810 SymbolicName=ERROR_DOMAIN_TRUST_INCONSISTENT diff --git a/po/ar.po b/po/ar.po index 9789501..7fd04e7 100644 --- a/po/ar.po +++ b/po/ar.po @@ -6328,15 +6328,18 @@ msgid "No more bindings.\n" msgstr "Ùا ÙÙجد ٠رابط إضاÙÙØ©.\n" #: winerror.mc:3446 -msgid "Can't logon with inter-domain trust account.\n" +#, fuzzy +msgid "Can't log on with inter-domain trust account.\n" msgstr "ÙÙ Ùت٠Ù٠٠٠اÙÙÙÙج Ø¥Ù٠اÙرابط اÙداخÙ٠٠ع Øساب Ù ÙØ«ÙÙ.\n" #: winerror.mc:3451 -msgid "Can't logon with workstation trust account.\n" +#, fuzzy +msgid "Can&#
Windows 7 64-bit?
I have to ask: Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTestingId=79589
Re: Windows 7 64-bit?
On 26/07/13 19:42, Rosanne DiMesio wrote: But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. This is a real pain. Was it intentional or a bug that's slipped in?
Re: Possibility of adding a new patch status
There's also "Pending". On 30/07/13 04:16, Hugh McMaster wrote: Hi everyone, Wine patches currently have a status described in http://source.winehq.org/patches, yet for patches with the status of 'New', the status becomes confusing. The legend describes 'New' status as "Patch not even looked at yet, there's still hope...". This is ideal for new patches submitted within that 24-hour commit cycle. But I'm finding it difficult to follow patches that remain with a status of 'New' for longer than the 24-hour patch cycle. Obviously, on the weekend, patches are held over till Monday, so a longer lead-time is expected. During weekdays, however, it is unclear what is happening with some patches. This, ultimately, raises the question of timeliness. Has the patch been looked at? If it has, the status often describes what action was taken - committed, rejected, superseded, etc. This is fine, but some patches remain with a status of 'New'. Experience has told me that patches remaining with a status of 'New' are incorrect in some way. But this is not always the case. If the patch is incorrect, but close to being accepted, the patch's status should reflect this, by changing to something like "Revision needed". Of course, the "Rejected" status is also appropriate, depending on the severity of coding error. Also, there are likely to be many times when the maintainer has not had time to evaluate some patches. This means the patch is not new (i.e. recently submitted), but is awaiting review. Once again, I believe the patch status should reflect this situation. The status could be "Not yet reviewed". In summary, the 'New' status should be reserved for patches that are actually new. Just some thoughts.
Re: po: Add English (Canada) resource [Take 2]
Please disregard this patch. I missed a couple of words and with those corrected en_CA.po becomes identical to en.po (except that "serialisation" is fuzzy) and Wine defaults to that anyway for Canadian English. Will re-submit if there are any changes (just noticed -able/-eable). Will keep an eye on the English translations. On 30/07/13 22:37, Ken Sharp wrote: - Re-based to latest git - Removed all the fuzzies thanks to http://www.etymonline.com/index.php Turns out all the -ise/-ize words used in Wine are of Latin origin anyway. Original Message Subject: po: Add English (Canada) resource Date: Mon, 22 Jul 2013 19:28:51 +0100 From: Ken Sharp To: wine-patc...@winehq.org Canadian English follows some British/French rules but not others. I have left some of the -ise/-ize words fuzzy because: "the etymological convention that verbs derived from Greek roots are spelled with -ize and those from Latin with -ise is preserved in that practice." http://en.wikipedia.org/wiki/Canadian_english#Spelling_and_dictionaries I tried looking for the origins of the words and I couldn't get any. The non-fuzzies are correct. With British, US and Canadian I believe all the English variations (used in Wine) are covered, except Philippines (follows US rules).
Re: Wiki RFC: Redirects, swarm tactics, etc.
I've just started looking at the Wiki myself. There's a lot of outdated stuff on there and it needs a lot of attention. There's little hope of me helping with anything related to the actual programming but I'm willing to help with other stuff. On 02/08/13 07:03, Kyle Auble wrote: So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. 1. Do we want some kind of guideline on redirects for the wiki? Some stable "interface" pages to the main site might be good, but beyond that, I think minimizing redirects makes sense in this use case. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts? 3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths). I'm cool with keeping the theme code for the near future; if and when we move it onto WineHQ's git server though, just let me know so I can note that I'm not upstream anymore. 4. Finally, spammers... they keep coming... and they're getting smarter. We can mostly stalemate them with the regex filter, but it blocks legit edits too sometimes (in very annoying fashion). In fact, I think there are a few of them that have learned to turn the filter against us by completely wiping pages with false positives so we can't revert the page. Are there any relatively easy things we could do to cut the spam? I don't know, but it's possible the newer version of Moinmoin has more potent anti-spam tools. -Kyle
Re: po: Add English (Canada) resource [Take 2]
With all the corrections in-place for Canadian English, the British English it defaults to is identical (as far as Wine is concerned). This patch has a couple of errors now so it can be disregarded. If a separate entry to en_CA is necessary then let me know and I'll resubmit with the changes, but for now I think it may be unnecessary. If future patches introduce any "awkward" words then I'll send an updated patch then. On 31/07/13 13:21, Ken Sharp wrote: Please disregard this patch. I missed a couple of words and with those corrected en_CA.po becomes identical to en.po (except that "serialisation" is fuzzy) and Wine defaults to that anyway for Canadian English. Will re-submit if there are any changes (just noticed -able/-eable). Will keep an eye on the English translations. On 30/07/13 22:37, Ken Sharp wrote: - Re-based to latest git - Removed all the fuzzies thanks to http://www.etymonline.com/index.php Turns out all the -ise/-ize words used in Wine are of Latin origin anyway. Original Message Subject: po: Add English (Canada) resource Date: Mon, 22 Jul 2013 19:28:51 +0100 From: Ken Sharp To: wine-patc...@winehq.org Canadian English follows some British/French rules but not others. I have left some of the -ise/-ize words fuzzy because: "the etymological convention that verbs derived from Greek roots are spelled with -ize and those from Latin with -ise is preserved in that practice." http://en.wikipedia.org/wiki/Canadian_english#Spelling_and_dictionaries I tried looking for the origins of the words and I couldn't get any. The non-fuzzies are correct. With British, US and Canadian I believe all the English variations (used in Wine) are covered, except Philippines (follows US rules).
appwiz: Correct Wine Mono installer title in several languages
Hi Alexandre, http://source.winehq.org/patches/data/97460 should be correct but would I be right in assuming you would rather have the changes made along with the next string for each language?
jscript FTBFS in Cygwin 1.7.22
Probably better to post this here rather than the forums: http://forum.winehq.org/viewtopic.php?f=2&t=19501 "Not sure if this is a Wine bug (as usual) so I'd rather put this here than to open a new bug. On Cygwin 1.7.22 the compilation stops at jscript, apparently a conflict in the declaration of dtoa. $ make ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o jscript_main.o /home/ken/wine-git/dlls/jscript/jscript_main.c ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o lex.o /home/ken/wine-git/dlls/jscript/lex.c ccache cc -c -I/home/ken/wine-git/dlls/jscript -I. -I/home/ken/wine-git/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O0 -D_WIN32 -o number.o /home/ken/wine-git/dlls/jscript/number.c /home/ken/wine-git/dlls/jscript/number.c:57:20: error: conflicting types for ‘dtoa’ In file included from /home/ken/wine-git/include/wine/port.h:47:0, from /home/ken/wine-git/dlls/jscript/number.c:20: /usr/include/stdlib.h:161:35: note: previous declaration of ‘dtoa’ was here Makefile:199: recipe for target `number.o' failed make: *** [number.o] Error 1 dlls/jscript/number.c: static inline void dtoa(double d, WCHAR *buf, int size, int *dec_point) /usr/include/stdlib.h: char * _EXFUN(dtoa,(double, int, int, int *, int*, char**));"
Re: appwiz: Correct Wine Mono installer title in several languages
On 02/08/13 10:57, Alexandre Julliard wrote: Ken Sharp writes: Hi Alexandre, http://source.winehq.org/patches/data/97460 should be correct but would I be right in assuming you would rather have the changes made along with the next string for each language? You say you want to catch the translators attention, but you are doing just the opposite. Changing the strings and unfuzzying them will only hide the fact that they need a review. That patch corrects the titles hence they don't need to be fuzzy, and the incorrect parts are still fuzzy. At the moment nobody is taking any notice except me because nobody knows there is a problem. With the title and description varying it should become glaringly obvious. As I said: this patch is correct. The fuzzy bits are still marked as fuzzy.
Re: appwiz: Correct Wine Mono installer title in several languages
On 02/08/13 12:05, Alexandre Julliard wrote: Ken Sharp writes: On 02/08/13 10:57, Alexandre Julliard wrote: Ken Sharp writes: Hi Alexandre, http://source.winehq.org/patches/data/97460 should be correct but would I be right in assuming you would rather have the changes made along with the next string for each language? You say you want to catch the translators attention, but you are doing just the opposite. Changing the strings and unfuzzying them will only hide the fact that they need a review. That patch corrects the titles hence they don't need to be fuzzy, and the incorrect parts are still fuzzy. At the moment nobody is taking any notice except me because nobody knows there is a problem. With the title and description varying it should become glaringly obvious. Not really, it's just a missing translation like any other. And it's a lot easier to find a fuzzy in a po file than to spot a missing translation somewhere in the UI. Right, and with this patch applied the errors in the title are corrected, and the errors in the description remain fuzzy. These errors have been present since Wine Mono was introduced.
Re: Vacation
On 02/08/13 21:02, Alexandre Julliard wrote: Folks, I'll be on vacation for the next 10 days, so you'll have to live without commits for a while... They let you have time off? Unbelievable! Have a good un!
po: Add English (Philippines) resource
Hi everyone, Would anyone mind looking at the attached patch? It adds the English (Philippines) resource by linking (or copying) the English (US) resource. See http://bugs.winehq.org/show_bug.cgi?id=23124 Actually, the attached version links to fr.po (French) to make testing much easier. The final won't do that. It's explained in the bug. I have tested this successfully in Linux only. I wanted to test others but: Cygwin 1.7.22: creates its own "symlink" but no translations are built at all. Compilation is basically broken. PC-BSD 9.1: complains about gettext although the config.log seems to complain about gm4. I gave up. OpenIndiana: can't seem to find its own packages. Gave up. Debian kFreeBSD: all sorts of problems in VBox. Might try again later. So clearly I've had no luck on other platforms. If anyone else could quickly test it, that would be great! Thanks to Austin and François for the help thus far. Of course, all feedback welcome. TIA, Ken >From 310719c3771a2713af2743667a3825a9bbec6a48 Mon Sep 17 00:00:00 2001 From: Ken Sharp Date: Tue, 30 Jul 2013 23:34:03 +0100 Subject: po: Add English (Philippines) resource --- .gitignore |1 + Make.rules.in|3 +++ Makefile.in |1 + configure|1 + configure.ac |1 + po/LINGUAS |1 + tools/make_makefiles |1 + 7 files changed, 9 insertions(+) diff --git a/.gitignore b/.gitignore index 8c51c2a..2a78316 100644 --- a/.gitignore +++ b/.gitignore @@ -283,6 +283,7 @@ loader/wine64-preloader loader/wine_info.plist msg.pot po/*.mo +po/en_PH.po programs/Makeprog.rules programs/rpcss/epm.h programs/rpcss/epm_s.c diff --git a/Make.rules.in b/Make.rules.in index b7b89f5..e98ce52 100644 --- a/Make.rules.in +++ b/Make.rules.in @@ -111,6 +111,9 @@ filter: dummy .svg.bmp: CONVERT="$(CONVERT)" ICOTOOL="$(ICOTOOL)" RSVG="$(RSVG)" $(BUILDIMAGE) $< $@ +$(top_srcdir)/po/en_PH.po: $(top_srcdir)/po/fr.po + $(LN_S) -f fr.po $@ + .po.mo: $(MSGFMT) -o $@ $< diff --git a/Makefile.in b/Makefile.in index 72161fc..57f912f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -52,6 +52,7 @@ include/stamp-h: include/config.h.in config.status .PHONY: __clean__ clean:: __clean__ + $(RM) po/en_PH.po distclean:: clean $(RM) config.* configure.lineno TAGS tags include/config.h include/stamp-h Makefile Make.tmp $(RM) -r autom4te.cache diff --git a/configure b/configure index 5b1e50f..c673e4c 100755 --- a/configure +++ b/configure @@ -16493,6 +16493,7 @@ da \ de \ el \ en \ +en_PH \ en_US \ eo \ es \ diff --git a/configure.ac b/configure.ac index f9e35e6..7df18ea 100644 --- a/configure.ac +++ b/configure.ac @@ -3258,6 +3258,7 @@ da \ de \ el \ en \ +en_PH \ en_US \ eo \ es \ diff --git a/po/LINGUAS b/po/LINGUAS index 091a734..a4c49e1 100644 --- a/po/LINGUAS +++ b/po/LINGUAS @@ -6,6 +6,7 @@ da de el en +en_PH en_US eo es diff --git a/tools/make_makefiles b/tools/make_makefiles index 566ca0d..2ba596f 100755 --- a/tools/make_makefiles +++ b/tools/make_makefiles @@ -98,6 +98,7 @@ my @ignores = ( "loader/wine_info.plist", "msg.pot", "po/*.mo", +"po/en_PH.po", "programs/winetest/build.nfo", "programs/winetest/build.rc", "rsrc.pot", -- 1.7.9.5
Re: po: Add English (Philippines) resource
On 05/08/13 10:41, Francois Gouget wrote: On Sun, 4 Aug 2013, Ken Sharp wrote: Hi everyone, Would anyone mind looking at the attached patch? I wonder if this is something that could be handled at the NLS level instead. Maybe in dlls/kernel32/nls/enp.nls. Would LOCALE_SNAME "en-PH" be relevant here? Or would it make sense to add a setting to map en_PH to en_US somehow? Otherwise the symlink approach sounds fine by me. I had a look in the kernel but I couldn't see any way to do it. If it can be done then that would be great. It would avoid creating an extra .mo, although that isn't the end of the world. I tried diff --git a/include/winnt.rh b/include/winnt.rh index 1013a24..45896ad 100644 --- a/include/winnt.rh +++ b/include/winnt.rh @@ -247,7 +247,7 @@ #define SUBLANG_ENGLISH_BELIZE 0x0a #define SUBLANG_ENGLISH_TRINIDAD 0x0b #define SUBLANG_ENGLISH_ZIMBABWE 0x0c -#define SUBLANG_ENGLISH_PHILIPPINES0x0d +#define SUBLANG_ENGLISH_PHILIPPINESSUBLANG_DEFAULT #define SUBLANG_ENGLISH_INDIA 0x10 #define SUBLANG_ENGLISH_MALAYSIA 0x11 #define SUBLANG_ENGLISH_SINGAPORE 0x12 or +#define SUBLANG_ENGLISH_PHILIPPINESSUBLANG_ENGLISH_US but this simply causes confusion. /home/test/wine-git/dlls/kernel32/nls/enp.nls:26:109: Error: Stringtable ID 88 already in use One problem to note is that if it maps everything to _DEFAULT or _US then it will lose details like LOCALE_SENGCOUNTRY "Republic of the Philippines" LOCALE_SENGCURRNAME "Philippine Peso" LOCALE_SINTLSYMBOL "PHP" LOCALE_SISO3166CTRYNAME "PH" LOCALE_SLANGUAGE "English (Philippines)" which of course would not be correct. Linking POs does avoid this. As an aside: #define SUBLANG_SINDHI_PAKISTANSUBLANG_SINDHI_AFGHANISTAN This may cause problems if these languages are ever implemented. Not sure if Wine handles these differently.
Re: po: Add English (Philippines) resource
On 05/08/13 12:00, Ken Sharp wrote: As an aside: #define SUBLANG_SINDHI_PAKISTANSUBLANG_SINDHI_AFGHANISTAN This may cause problems if these languages are ever implemented. Not sure if Wine handles these differently. And then, of course, I realise that these are probably the same languages and will never need to be implemented separately. #define SUBLANG_ENGLISH_IRELANDSUBLANG_ENGLISH_EIRE #define SUBLANG_HAUSA_NIGERIA SUBLANG_HAUSA_NIGERIA_LATIN #define SUBLANG_LAO_LAO_PDRSUBLANG_LAO_LAO #define SUBLANG_PORTUGUESE_PORTUGALSUBLANG_PORTUGUESE #define SUBLANG_SWAHILISUBLANG_SWAHILI_KENYA #define SUBLANG_SWEDISH_SWEDEN SUBLANG_SWEDISH #define SUBLANG_SYRIAC SUBLANG_SYRIAC_SYRIA
Re: inputscope.idl: Imported from mingw-w64.
On 05/08/13 12:14, Jacek Caban wrote: + * No warranty is given; refer to the file DISCLAIMER.PD within this package. It's a minor point but this may be a bit confusing given the file doesn't exist.
Fwd: [AppDB] Submitted test data deleted
Deleting test results because the Wine version is old? What the Hell is the plan there? Original Message Subject: [AppDB] Submitted test data deleted Date: Mon, 05 Aug 2013 15:48:43 -0500 From: AppDB Reply-To: AppDB To: appdb-nore...@winehq.org Submitted test data deleted --- The test report you submitted for 'Microsoft Access 2007' has been deleted. The action was performed by Joerg Schiermeier Reasons given Old wine - deprecated. Best regards. The AppDB team http://appdb.winehq.org/ If you don't want to receive any other e-mail, please change your preferences: http://appdb.winehq.org/preferences.php
Re: Request to add wow64 keyword to bugzilla
On 07/08/13 13:59, Rosanne DiMesio wrote: Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit wineprefix. I'm interested in being able to track the latter, as it's hitting increasing numbers of users. The win64 keyword should only be used when 64-bit code is used and is the problem. It shouldn't be used just because the WINEPREFIX is 64-bit or that would be all Ubuntu users on AMD64 using the standard packages. Would I be right in assuming you would like to see bugs in 32-bit applications that are only present in a wow64 WINEPREFIX? Are there many?
Re: Request to add wow64 keyword to bugzilla
+1 from me. On 07/08/13 15:03, Rosanne DiMesio wrote: On Wed, 07 Aug 2013 14:23:53 +0100 Ken Sharp wrote: Would I be right in assuming you would like to see bugs in 32-bit applications that are only present in a wow64 WINEPREFIX? Are there many? Yes. As to how many there are, I've been able to find 7 by doing searches of summaries/comments for things like "wow64" and "64" and then reading the bugs to see if they fit, but since people have such wildly varying ways of phrasing things, I don't know if that's all of them. I have seen it often enough on the forum that I now routinely tell 64 bit users to try a 32 bit wineprefix and have added instructions on how to create one to the FAQ. That's why I'd like an easier way to track these bugs. I see. A lot of people say this over and over again. +1 from me for a wow64 keyword. They may even be fairly easy to solve (picking the right paths / registry entries). As to keyword usage, some of those bugs were tagged with the win64 keyword, some weren't. I know there is also a win32 keyword, and perhaps that is meant to be used for the kinds of bugs I am looking for, but if so, that is not at all clear from the keyword definition, and it is not how people are using the keywords. There's no win32 keyword?
Compiler warnings on Debian kfreebsd-i386
Some interesting, some not: /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1898:24: warning: ‘get_pid_map’ defined but not used [-Wunused-function] /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1953:21: warning: ‘find_owning_pid’ defined but not used [-Wunused-function] /home/ken/wine-git/dlls/jscript/parser.y: conflicts: 1 shift/reduce, 18 reduce/reduce /home/ken/wine-git/dlls/msi/sql.y: conflicts: 1 reduce/reduce /home/ken/wine-git/dlls/ntdll/directory.c: In function ‘wine_getdirentries’: /home/ken/wine-git/dlls/ntdll/directory.c:1710:5: warning: passing argument 4 of ‘getdirentries’ from incompatible pointer type [enabled by default] In file included from /home/ken/wine-git/dlls/ntdll/directory.c:29:0: /usr/include/dirent.h:313:18: note: expected ‘__off_t * __restrict__’ but argument is of type ‘long int *’ /home/ken/wine-git/dlls/vbscript/parser.y: conflicts: 6 shift/reduce /home/ken/wine-git/programs/winedbg/dbg.y: conflicts: 1 shift/reduce, 1 reduce/reduce /home/ken/wine-git/programs/winedbg/dbg.y: conflicts: 1 shift/reduce, 1 reduce/reduce
Re: Compiler warnings on Debian kfreebsd-i386
On 08/08/13 21:28, Charles Davis wrote: On Aug 8, 2013, at 8:20 AM, Ken Sharp wrote: Some interesting, some not: /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1898:24: warning: ‘get_pid_map’ defined but not used [-Wunused-function] /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1953:21: warning: ‘find_owning_pid’ defined but not used [-Wunused-function] I have a patch to fix those (and another one to fix them on Mac OS), but there's a bunch of patches ahead of it in my queue. Also, the patch was designed for standard FreeBSD (it needs libprocstat), so I'm not sure how well it will work on GNU/kFreeBSD. I've attached both patches so you can test it. N.B. the Mac OS patch needs to be applied first--it was developed first, and it implements the guts of the GetExtended*Table functions that actually call those functions. Also, you'll need to run autoreconf(1) after applying: the patches contain changes to configure.ac, but not configure or include/config.h.in. Unfortunately the build breaks with the two patches applied in Wine 1.7.0. winegcc: File does not exist: @LIBPROCSTAT@ make[1]: *** [iphlpapi.dll.so] Error 2 make: *** [dlls/iphlpapi] Error 2 The patches were applied cleanly.
Re: Compiler warnings on Debian kfreebsd-i386
On 10/08/13 00:01, Charles Davis wrote: Did you run autoreconf like I said? No! I'm useless! I'll get back to you tomorrow. Sorry. :(
Re: Compiler warnings on Debian kfreebsd-i386
On 08/08/13 21:28, Charles Davis wrote: On Aug 8, 2013, at 8:20 AM, Ken Sharp wrote: Some interesting, some not: /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1898:24: warning: ‘get_pid_map’ defined but not used [-Wunused-function] /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1953:21: warning: ‘find_owning_pid’ defined but not used [-Wunused-function] I have a patch to fix those (and another one to fix them on Mac OS), but there's a bunch of patches ahead of it in my queue. Also, the patch was designed for standard FreeBSD (it needs libprocstat), so I'm not sure how well it will work on GNU/kFreeBSD. I've attached both patches so you can test it. N.B. the Mac OS patch needs to be applied first--it was developed first, and it implements the guts of the GetExtended*Table functions that actually call those functions. Also, you'll need to run autoreconf(1) after applying: the patches contain changes to configure.ac, but not configure or include/config.h.in. /home/ken/wine-git/dlls/ntdll/directory.c: In function ‘wine_getdirentries’: /home/ken/wine-git/dlls/ntdll/directory.c:1710:5: warning: passing argument 4 of ‘getdirentries’ from incompatible pointer type [enabled by default] In file included from /home/ken/wine-git/dlls/ntdll/directory.c:29:0: /usr/include/dirent.h:313:18: note: expected ‘__off_t * __restrict__’ but argument is of type ‘long int *’ This one has to do with the actual getdirentries(2) prototype: int getdirentries(int, char *, int, long *); glibc's prototype is broken. It really is a 'long *', not an 'off_t *' (don't believe me? Go read the syscalls.master file in the kernel source). Or, maybe they're aware of this, and glibc's getdirentries(2) stub extends the 32-bit long (on a 32-bit system) into an off_t--in which case, we'll need a configure check for this. Chip All looks good here. No warnings, no failures. $ uname -srmvpio GNU/kFreeBSD 9.0-2-686 #0 Sun Jun 23 17:53:03 UTC 2013 i386 i386 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/kFreeBSD $ ~/wine32/wine --version wine-1.7.0 There are a few test failures but I don't think that they are related (fixmes). fixme:iphlpapi:SetTcpEntry (pTcpRow 0x33fcc8): stub iphlpapi.c:855: Test failed: got 0, expected 87 fixme:iphlpapi:SetTcpEntry (pTcpRow 0x33fcc8): stub iphlpapi.c:859: Test failed: got 0, expected 317 fixme:iphlpapi:NotifyAddrChange (Handle 0x33fcb4, overlapped 0x33fcb8): stub iphlpapi.c:1055: Test failed: GetLastError returned 203, expected ERROR_IO_PENDING fixme:iphlpapi:CancelIPChangeNotify (overlapped 0x33fcb8): stub iphlpapi.c:1057: Test failed: CancelIPChangeNotify returned FALSE, expected TRUE fixme:iphlpapi:CancelIPChangeNotify (overlapped 0x33fcb8): stub fixme:iphlpapi:NotifyAddrChange (Handle 0x33fcb4, overlapped 0x33fcb8): stub iphlpapi.c:1068: Test failed: NotifyAddrChange returned invalid file handle fixme:iphlpapi:CancelIPChangeNotify (overlapped 0x33fcb8): stub iphlpapi.c:1074: Test failed: CancelIPChangeNotify returned FALSE, expected TRUE
