Request to delete some attachments
Could a Bugzilla admin please delete the attachments in http://bugs.winehq.org/show_bug.cgi?id=24867 ? I don't know if metatester.exe can be freely distributed.
Re: PLEASE add bug links!
On 18/08/13 09:56, Francois Gouget wrote: On Fri, 16 Aug 2013, Rosanne DiMesio wrote: On Fri, 16 Aug 2013 20:51:19 +0100 Ken Sharp kennyb...@o2.co.uk wrote: I believe someone managed to run a script to find the unlinked bugs. I can't remember who it was now, sadly, and I don't know if it was server-side, which would obviously be quicker. Dan Kegel. http://kegel.com/wine/unlinked.html This page seems to list a lot of closed bugs. Do we want to bother linking the AppDB to those? If not it would probably be relatively easy to remove them from the list which would make finding the remaining offenders easier. It's an old list. Another problem with that list is that some bugs correspond to no specific Windows application (e.g. 'Stabilize Winelib User Guide Table of Contents') and thus will never be linked from the AppDB. As a result they will remain in this 'todo' list indefinitely. It would be goo to have a way to get them removed. One possibility would be to have a button or some such on the page, but it might be better to have some kind of indication directly in Bugzilla, maybe a keyword? There was one: NoAppDBEntry. It was removed for some reason. In case someone would like to improve the script producing this page, is its source available somewhere?
Re: PLEASE add bug links!
On 18/08/13 10:16, Francois Gouget wrote: On Fri, 16 Aug 2013, Ken Sharp wrote: [...] It takes longer to create a bug report than it does to link it to the database. It really isn't that hard. But adding a link requires going and logging into a separate web site. That's really not the part of the normal flow of entering a bug. It is for me and everyone else who actually does it. It's nothing more than your choice not to. There's no normal flow to entering a bug. I've already said that it takes seconds. There's little point in my continually asking users to add bug links to the AppDB if maintainers and/or administrators don't bother themselves. [...] I've added hundreds over the past few weeks and this is not the first time I have said it, nor am I the first one to do so. It's even on the Wiki. http://wiki.winehq.org/Bugs Who reads instructions on a separate Wiki page when entering bug reports? Just saying your expectations may be set a bit unrealistically high. Really? We may as well delete all the Wiki pages then. https://wiki.ubuntu.com/Lubuntu/ReportingBugs http://fedoraproject.org/wiki/How_to_file_a_bug_report https://wiki.videolan.org/Report_bugs/ http://www.mingw.org/Reporting_Bugs The triage team link to the Wiki with almost every response for more information. We have some instructions on Bugzilla's bug submission page (currently 'Please do not PASTE logs and back traces'). It may make sense to add something for the bug links either there or on the page confirming the bug was enered. It would have a much better chance of being read there than on the Wiki. Just add the link to the Wiki. We've already done that on the AppDB. The Wiki can be easily edited. Bugzilla cannot.
Re: PLEASE add bug links!
On 18/08/13 17:35, Francois Gouget wrote: On Sun, 18 Aug 2013, Ken Sharp wrote: [...] We have some instructions on Bugzilla's bug submission page (currently 'Please do not PASTE logs and back traces'). It may make sense to add something for the bug links either there or on the page confirming the bug was enered. It would have a much better chance of being read there than on the Wiki. Just add the link to the Wiki. It's there already. Since you don't seem to know that it means you've either never entered a Wine bug (but you made claims that seem to indicate the contrary), or that you yourself don't read the instructions on how to enter a bug. So why do you expect others to? I know it's already there. Given I have just update a load of Wiki links on how to correctly do all of this, who are you trying to blame for not read this stuff? So I stand by my assessement that you have unrealistically high expectations of others, You aim very low. and that going to a separate website is not part of the normal workflow for entering a bug. For you. Other users manage it. It takes them seconds. I'll also add that I've been entering Wine bugs for about as long as is possible and I was not aware of the requirement to add the bugs in the AppDB. You have been paying very little attention then as it has been brought up a number of times. It is also IN THE WIKI! Note that I'm not saying it wouldn't be nice to have the AppDB and Bugzilla nicely cross-referenced or that we shouldn't strive for it. What I'm saying is: * As things stand you cannot act all surprised that it's not the case. * Putting all the blame on the bug reporters like you seem to be doing is not how you will improve the situation. So who is to blame? Is it your fault? It's not mine. Perhaps you are blaming Codeweavers? Who is to blame for the inaction of others if it not the people themselves?
Re: PLEASE add bug links!
On 17/08/13 13:36, Rosanne DiMesio wrote: On Sat, 17 Aug 2013 13:07:32 +0200 André Hentschel n...@dawncrow.de wrote: So this is just with no link in Show Apps affected by this bug? Beside it being outdated i think it's not exactly what Ken wants, I can, and do, search Bugzilla for that. It is a massive PITA having to do it but a script would make it easier, however... I think what Ken wants is for people to add the bug links when they create the bug so we don't periodically wind up with thousands of unlinked bugs that have to be cleaned up. Spot on. It may seem counter-productive but I agree that you shouldn't be forced to create an AppDB account, despite it not hurting in the slightest. The problem though is that most people do have both accounts, they're just too damned lazy to attach the bug link. As a general rule the AppDB admins and the Bugzilla triage team are the same people, and it's these poor buggers that have to clean up all the mess where people could be doing it themselves. Many a hand makes light work... Do your part... Dig for victory... etc.
Re: [website] Added templates/zh-cn/cvs.template translation
On 17/08/13 09:02, Frédéric Delanoy wrote: Hwang YunSong (황윤성) Looks like UTF-8 works fine, so you could always use your real Chinese name. 황윤성 is Korean I believe.
PLEASE add bug links!
There's little point in my continually asking users to add bug links to the AppDB if maintainers and/or administrators don't bother themselves. It takes longer to create a bug report than it does to link it to the database. It really isn't that hard. I've added hundreds over the past few weeks and this is not the first time I have said it, nor am I the first one to do so. It's even on the Wiki. http://wiki.winehq.org/Bugs
Re: Sort the AUTHORS file by their last names.
On 16/08/13 14:46, Tae Wong wrote: The AUTHORS file have all developers from the GIT log which were sorted on their first names. This patch will switch the sort order from first to last names. This isn't how the AUTHORS file is generated. http://source.winehq.org/git/wine.git/commit/5da31c8817293ff98b4defceb962f7d0fbc25829
Re: PLEASE add bug links!
On 16/08/13 19:15, Vincent Povirk wrote: If we really want the links to be up to date, we should figure out a way to make them show up on bugzilla, without clicking through to a search. Otherwise, the only time someone is likely to notice a bug that hasn't been linked is if they're looking for it specifically and happened to start their search on the appdb. Yep! Very true! I believe someone managed to run a script to find the unlinked bugs. I can't remember who it was now, sadly, and I don't know if it was server-side, which would obviously be quicker.
Re: Sort the AUTHORS file by their last names.
This is clearly going nowhere.
Re: PLEASE add bug links!
On 16/08/13 22:02, Rosanne DiMesio wrote: Dan Kegel. http://kegel.com/wine/unlinked.html Good find! :-)
Re: msvcrt: add support for _chsize_s
On 14/08/13 20:08, morphiend wrote: -@ stub _chsize_s +@ cdecl _chsize_s(long int64) msvcrt._chsize +#@ stub _chsize_s Oops..
Compiler warnings on Debian Sid kfreebsd-i386
Following my previous e-mail (http://www.winehq.org/pipermail/wine-devel/2013-August/100754.html) I have since moved from Wheezy to Sid to work around a Debian bug. libxml2 has been updated (2.8.0+dfsg1-7+nmu1 -- 2.9.1+dfsg1-3) as a result and introduced some new compiler warnings: /home/ken/wine-git/dlls/msxml3/node.c: In function ‘htmldtd_dumpcontent’: /home/ken/wine-git/dlls/msxml3/node.c:908:9: warning: passing argument 1 of ‘xmlBufferWriteQuotedString’ from incompatible pointer type [enabled by default] xmlBufferWriteQuotedString(buf-buffer, cur-ExternalID); ^ In file included from /usr/include/libxml2/libxml/parser.h:16:0, from /home/ken/wine-git/dlls/msxml3/node.c:28: /usr/include/libxml2/libxml/tree.h:1123:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’ xmlBufferWriteQuotedString(xmlBufferPtr buf, ^ /home/ken/wine-git/dlls/msxml3/node.c:912:13: warning: passing argument 1 of ‘xmlBufferWriteQuotedString’ from incompatible pointer type [enabled by default] xmlBufferWriteQuotedString(buf-buffer, cur-SystemID); ^ In file included from /usr/include/libxml2/libxml/parser.h:16:0, from /home/ken/wine-git/dlls/msxml3/node.c:28: /usr/include/libxml2/libxml/tree.h:1123:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’ xmlBufferWriteQuotedString(xmlBufferPtr buf, ^ /home/ken/wine-git/dlls/msxml3/node.c:918:9: warning: passing argument 1 of ‘xmlBufferWriteQuotedString’ from incompatible pointer type [enabled by default] xmlBufferWriteQuotedString(buf-buffer, cur-SystemID); ^ In file included from /usr/include/libxml2/libxml/parser.h:16:0, from /home/ken/wine-git/dlls/msxml3/node.c:28: /usr/include/libxml2/libxml/tree.h:1123:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’ xmlBufferWriteQuotedString(xmlBufferPtr buf, ^ /home/ken/wine-git/dlls/msxml3/node.c: In function ‘node_transform_node’: /home/ken/wine-git/dlls/msxml3/node.c:974:21: warning: passing argument 1 of ‘xmlBufferContent’ from incompatible pointer type [enabled by default] content = xmlBufferContent(output-buffer); ^ In file included from /usr/include/libxml2/libxml/parser.h:16:0, from /home/ken/wine-git/dlls/msxml3/node.c:28: /usr/include/libxml2/libxml/tree.h:734:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’ xmlBufferContent (const xmlBufferPtr buf); ^ Hopefully these mean something to someone.
Re: Compiler warnings on Debian Sid kfreebsd-i386
On 12/08/13 20:15, Mislav Blazevic wrote: It seems that xmlBufPtr was renamed to xmlBufferPtr in new libxml. It does seem that way. :-) Or maybe :-(
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
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. :(
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: 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 kennyb...@o2.co.uk 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?
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 appdb-nore...@winehq.org Reply-To: AppDB appdb-nore...@winehq.org 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
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 kennyb...@o2.co.uk 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: 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 kennyb...@o2.co.uk 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=2t=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 kennyb...@o2.co.uk 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 kennyb...@o2.co.uk writes: On 02/08/13 10:57, Alexandre Julliard wrote: Ken Sharp kennyb...@o2.co.uk 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!
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 kennyb...@o2.co.uk 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: 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.
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=versioniId=28587iTestingId=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?
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 kennyb...@o2.co.uk 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't log on with workstation trust account.\n msgstr ÙÙ Ùت٠Ù٠٠٠اÙÙÙÙج Ø¥Ù٠اÙÙ Øطة ٠ع Øساب Ù ÙØ«ÙÙ.\n #: winerror.mc:3456 -msgid Can't logon with server trust account
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).
Re: appwiz: Correct Wine Mono installer messages
On 22/07/13 18:37, Alexandre Julliard wrote: Ken Sharp kennyb...@o2.co.uk 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 bungleh...@gmail.com 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: Another major milestone
On 19/07/13 15:00, Rosanne DiMesio wrote: On Thu, 18 Jul 2013 16:55:42 -0500 Jeremy White jwh...@codeweavers.com 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*
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
Please remove this email address
Hi, I have been receiving daily digests from this mailbox for a while. I tried emailing the list owner according to the website but that had no effect. I have been filtering the digests away so I didn't see that people had replied (thanks to everyone who did, sorry I haven't replied). I have tried changing the preferences but it just tells me that this email address doesn't exist. I can't do anything with this. Could someone with relevant access please remove me so that I can add myself again, properly? Thanks, Ken
kernel32: Update English resource
I suspect this is the wrong way to update the US English resource for an .mc file. Could anyone comment? Thanks From bcf976540aa3707e2b39f8133799e50e9fab9580 Mon Sep 17 00:00:00 2001 From: Ken Sharp kennyb...@o2.co.uk Date: Fri, 28 Oct 2011 15:57:52 +0100 Subject: [PATCH 2/2] kernel32: Update English (Neutral) resource --- dlls/kernel32/winerror.mc | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/dlls/kernel32/winerror.mc b/dlls/kernel32/winerror.mc index 9f69784..fcd2092 100644 --- a/dlls/kernel32/winerror.mc +++ b/dlls/kernel32/winerror.mc @@ -276,7 +276,7 @@ No spool space MessageId=63 SymbolicName=ERROR_PRINT_CANCELLED Language=ENU -Print cancelled +Print canceled . MessageId=64 SymbolicName=ERROR_NETNAME_DELETED @@ -881,7 +881,7 @@ More data available MessageId=240 SymbolicName=ERROR_VC_DISCONNECTED Language=ENU -Session cancelled +Session canceled . MessageId=254 SymbolicName=ERROR_INVALID_EA_NAME @@ -1741,7 +1741,7 @@ No network MessageId=1223 SymbolicName=ERROR_CANCELLED Language=ENU -Operation cancelled by user +Operation canceled by user . MessageId=1224 SymbolicName=ERROR_USER_MAPPED_FILE @@ -3496,7 +3496,7 @@ No interfaces MessageId=1818 SymbolicName=RPC_S_CALL_CANCELLED Language=ENU -RPC call cancelled +RPC call canceled . MessageId=1819 SymbolicName=RPC_S_BINDING_INCOMPLETE @@ -3536,7 +3536,7 @@ Security package error MessageId=1826 SymbolicName=RPC_S_NOT_CANCELLED Language=ENU -Thread not cancelled +Thread not canceled . MessageId=1827 SymbolicName=RPC_X_INVALID_ES_ACTION -- 1.7.5.1
Re: Anyone wants to ban spammer on forum
On 20/10/11 4:13 PM, Bruno Jesus wrote: On Thu, Oct 20, 2011 at 11:48, Jeremy Newmanjnew...@codeweavers.com wrote: I will take suggestions on other questions that regular users can answer easily, but would stump (for a bit anyway) a bot, or bot author. Why not the good and old random math questions inside an image? For example 2 + 4 = ... A bot should be able to figure that out too, unless the answer is also a picture. Maybe A+B = ? The answer being AB. Don't know if any of this is possible with the software, however.
Re: Anyone wants to ban spammer on forum
Isn't the system for creating new accounts only? If it's just to post messages then anything will be annoying. On 20/10/11 7:48 PM, Jerome Leclanche wrote: Unless you want to implement a captcha system, any system is going to annoy the users. Bots can be programmed to answer those fields pretty easily; if a spammer wants to get around it, they will :) JL On Thu, Oct 20, 2011 at 7:24 PM, Ken Sharpkennyb...@o2.co.uk wrote: On 20/10/11 4:13 PM, Bruno Jesus wrote: On Thu, Oct 20, 2011 at 11:48, Jeremy Newmanjnew...@codeweavers.com wrote: I will take suggestions on other questions that regular users can answer easily, but would stump (for a bit anyway) a bot, or bot author. Why not the good and old random math questions inside an image? For example 2 + 4 = ... A bot should be able to figure that out too, unless the answer is also a picture. Maybe A+B = ? The answer being AB. Don't know if any of this is possible with the software, however.
Re: Anyone wants to ban spammer on forum
Here here On 20/10/11 8:17 PM, Jerome Leclanche wrote: I think that's a great system, but you'll need volunteers :) I can volunteer for that matter, but I won't exactly spend a lot of time on it. JL On Thu, Oct 20, 2011 at 8:07 PM, Josh Juranj...@iswifter.net wrote: On Oct 20, 2011, at 11:58 AM, Jerome Leclanche wrote: I don't subscribe to websites that have annoying captchas either way; and many people are like that. Bot authors have proved they can beat any system; and captchas (recaptcha especially) has proved itself as one of the most effective and unintrusive free captcha systems. Quarantine new users' posts until approved by a human moderator. After a few intelligent posts, grant the user unmoderated posting privilege. The Boost mailing list does this. Josh
Re: Anyone wants to ban spammer on forum
On 19/10/11 03:37, Vitaliy Margolen wrote: On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. So no takers? I'm guessing we need more forum admins then, so more timezones can be covered. I rarely use the forums but if it's that bad I would happily look in a few times a day. UTC+1 Vitaliy.
Re: Regression testing breakthrough
On 19/10/11 13:43, Frédéric Delanoy wrote: On Wed, Oct 19, 2011 at 14:08, Joel Holdsworthj...@airwebreathe.org.uk wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? tar.xz would compress better tar.lzma?
Re: Anyone wants to ban spammer on forum
On 19/10/11 16:49, Jeremy Newman wrote: On 10/19/2011 10:21 AM, Tijl Coosemans wrote: The past few days there's been spam messages every few minutes and as soon as you ban an account an other one appears. Obviously the bots have figured out the answer to the captcha. Alrighty then, time for me to change the question... Done! The new question is: What operating system does Wine run applications from? Should be obvious for a human. Including the human who wrote the bot? -N
Re: po: Update English (US) translation
On 18/10/11 15:23, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk writes: From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 From: Ken Sharpkennyb...@o2.co.uk Date: Sat, 15 Oct 2011 03:50:43 +0100 Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. Okay that should be simple enough, but what is po/en_US.po for then? Won't the translations in en_US.po override any US translations in the .rc files?
Re: po: Update English (US) translation
On 18/10/11 16:15, Frédéric Delanoy wrote: On Tue, Oct 18, 2011 at 17:01, Francois Gougetfgou...@free.fr wrote: My understanding it that en.po contains the British translation and is treated as just another translation. So instead of containing just the strings that need to be different, all the other strings are copied as well by the translators so they know what has been checked already. For clarity, we should probably have no en_US.po but only en.po (and possibly other en_XX.po like en_GB.po) maybe a soft link from en_US.po to en.po to make it clear) If en.po is British English there will be a fair few differences for en_US.po (and en_PH.po). The current situation (en.po and en_US.po) makes it look like en_US.po is an adapted version of standard en.po (which is then presumably en_GB), as is e.g. fr_CA vs fr.po This is not the first time someone adapts the en_US.po IIRC. Frédéric
Re: po: Update English (US) translation
On 18/10/11 17:05, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk writes: Okay that should be simple enough, but what is po/en_US.po for then? Won't the translations in en_US.po override any US translations in the .rc files? Yes, but in general they should be identical. We have en_US.po because there are cases where strings need to be different, for instance when the .rc string contains a context, or non-ASCII chars. So any changes made should be in both the .rc files AND the .po files to keep them in sync?
Re: po: Update English (US) translation
On 18/10/11 6:35 PM, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk writes: So any changes made should be in both the .rc files AND the .po files to keep them in sync? I resynchronize en_US.po when committing, so you don't need to submit that part. Excellent, thanks Alexandre, that's what I was looking for. I'll resubmit.
Re: po: Update English (US) translation
On 18/10/11 6:35 PM, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk writes: So any changes made should be in both the .rc files AND the .po files to keep them in sync? I resynchronize en_US.po when committing, so you don't need to submit that part. http://source.winehq.org/patches/data/79974 This should be right then?
Fix Bug 23124 with an ln -s
http://bugs.winehq.org/show_bug.cgi?id=23124 Could someone tell me if the attached patch would actually work? It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know that: 1. Using an ln -s is acceptable, nor if it will work given some file systems may be unable to use soft links. 2. I have correctly edited configure, configure.ac and LINGUAS, or even if I need to edit both. Thanks all, Ken From f05f2b6c877b28984085299635adc2f137ef5300 Mon Sep 17 00:00:00 2001 From: Ken Sharp kennyb...@o2.co.uk Date: Sat, 15 Oct 2011 15:14:48 +0100 Subject: [PATCH] po: Add English (Philippines) translation Philippines English follows US English rules, so a simple link will keep the two in sync. --- configure|1 + configure.ac |1 + po/LINGUAS |1 + po/en_PH.po |1 + 4 files changed, 4 insertions(+), 0 deletions(-) create mode 12 po/en_PH.po diff --git a/configure b/configure index 3cf9675..1bde5df 100755 --- a/configure +++ b/configure @@ -15284,6 +15284,7 @@ da \ de \ el \ en \ +en_PH \ en_US \ eo \ es \ diff --git a/configure.ac b/configure.ac index 5de420b..d323175 100644 --- a/configure.ac +++ b/configure.ac @@ -2987,6 +2987,7 @@ da \ de \ el \ en \ +en_PH \ en_US \ eo \ es \ diff --git a/po/LINGUAS b/po/LINGUAS index ac9935c..cb29ec1 100644 --- a/po/LINGUAS +++ b/po/LINGUAS @@ -6,6 +6,7 @@ da de el en +en_PH en_US eo es diff --git a/po/en_PH.po b/po/en_PH.po new file mode 12 index 000..2ed6a9a --- /dev/null +++ b/po/en_PH.po @@ -0,0 +1 @@ +en_US.po \ No newline at end of file -- 1.7.4.1
Re: ntdll: Add Windows XP x64
Yep. That makes more sense. It's certainly beyond my capability. The only problem then is people wanting to run 32-bit apps with 16-bit code on a 64-bit system in XP mode might have all kinds of problems if the app first checks which kernel is in use - MS in their obvious wisdom have removed the 16-bit VM from XP x64, so there probably still needs to be an option to choose the kernel version. AFAIK it's only XP that has this problem, other 32/64 versions use the same build numbers. Hurray for Windows. On 15/04/11 14:19, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk writes: Windows XP x64 has an updated kernel to XP, so just setting XP in winecfg will still cause apps to fail. IE8 for XP x64 is an example. This should most likely be done automatically on 64-bit.
po: Update US English resource
http://www.winehq.org/pipermail/wine-devel/2011-April/089585.html (I lost the original mail - along with a bunch of others) I'm confused as to what the .po files are for. ise/ize will be correct if the .rc file default is British English. Without updating the .po file for US English I don't see how else this can be updated - unless it is simply the way it was before with LANG_ and SUBLANG_, but then what are the .po files for? I can't find any details in the Wiki and I'm afraid I wasn't around when they were introduced...
ntdll: Add support for Windows XP 64-bit
Morning all,
Could someone far smarter than me please take a look at the attached patch?
Windows XP 64-bit runs NT kernel 5.2, whereas 32-bit runs 5.1. Any
64-bit app expecting XP 64-bit will fail (such as IE8 for NT 5.2).
The patch lets the installer continue, but I'm not sure if it is enough
to be accepted.
For example, do I need to winxp,winxp64, here?
http://source.winehq.org/source/dlls/ntdll/version.c?v=wine-1.3.17#L172
TIA,
Ken.
From 6e89cbab2ac50927b9fd1f9c39e633fe8b3289d8 Mon Sep 17 00:00:00 2001
From: Ken Sharp kennyb...@o2.co.uk
Date: Wed, 13 Apr 2011 05:32:53 +0100
Subject: ntdll: Add support for Windows XP 64-bit
---
dlls/ntdll/version.c |7 +++
programs/winecfg/appdefaults.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/version.c b/dlls/ntdll/version.c
index 46385c9..dfb6ef6 100644
--- a/dlls/ntdll/version.c
+++ b/dlls/ntdll/version.c
@@ -50,6 +50,7 @@ typedef enum
NT40,/* Windows NT 4.0 */
NT2K,/* Windows 2000 */
WINXP, /* Windows XP */
+WINXP64, /* Windows XP 64-bit */
WIN2K3, /* Windows 2003 */
WINVISTA,/* Windows Vista */
WIN2K8, /* Windows 2008 */
@@ -132,6 +133,12 @@ static const RTL_OSVERSIONINFOEXW VersionData[NB_WINDOWS_VERSIONS] =
{'S','e','r','v','i','c','e',' ','P','a','c','k',' ','3',0},
3, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */
},
+/* WINXP64 */
+{
+sizeof(RTL_OSVERSIONINFOEXW), 5, 2, 0xECE, VER_PLATFORM_WIN32_NT,
+{'S','e','r','v','i','c','e',' ','P','a','c','k',' ','2',0},
+2, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0
+},
/* WIN2K3 */
{
sizeof(RTL_OSVERSIONINFOEXW), 5, 2, 0xECE, VER_PLATFORM_WIN32_NT,
diff --git a/programs/winecfg/appdefaults.c b/programs/winecfg/appdefaults.c
index 6101c48..651d964 100644
--- a/programs/winecfg/appdefaults.c
+++ b/programs/winecfg/appdefaults.c
@@ -53,6 +53,7 @@ static const struct
{ win2008, Windows 2008, 6, 0, 0x1771,VER_PLATFORM_WIN32_NT, Service Pack 1, 0, 0, ServerNT},
{ vista, Windows Vista, 6, 0, 0x1772,VER_PLATFORM_WIN32_NT, Service Pack 2, 2, 0, WinNT},
{ win2003, Windows 2003, 5, 2, 0xECE, VER_PLATFORM_WIN32_NT, Service Pack 2, 2, 0, ServerNT},
+{ winxp64, Windows XP 64-bit, 5, 2, 0xECE, VER_PLATFORM_WIN32_NT, Service Pack 2, 2, 0, WinNT},
{ winxp, Windows XP, 5, 1, 0xA28, VER_PLATFORM_WIN32_NT, Service Pack 3, 3, 0, WinNT},
{ win2k, Windows 2000, 5, 0, 0x893, VER_PLATFORM_WIN32_NT, Service Pack 4, 4, 0, WinNT},
{ winme, Windows ME, 4, 90, 0xBB8, VER_PLATFORM_WIN32_WINDOWS, , 0, 0, },
--
1.7.1
Re: sane.ds: Change ns to ms in resource files
On 7/7/2010 10:30 AM, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk 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 Sharpkennyb...@o2.co.uk 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 Sharpkennyb...@o2.co.ukwrites: 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.
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: 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 : + PUSHBUTTONReset, IDC_RESET_BTN,308,23,44,14 : + PUSHBUTTONHelp, IDC_HELP_BTN,308,40,44,14 : + PUSHBUTTONMove Up, IDC_MOVEUP_BTN,308,74,44,14 : + PUSHBUTTONMove Down, IDC_MOVEDN_BTN,308,91,44,14 : + LTEXT Available 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 : + PUSHBUTTONAdd -,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 juan.l...@gmail.com 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: avifil32: Update English resource
On 15/06/10 09:00, Alexandre Julliard wrote: Ken Sharpkennyb...@o2.co.uk 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: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: 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?
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: 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.
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: 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: 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: 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: 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.
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: 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
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: 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
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
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=versioniId=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 wine-de...@kievinfo.com 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=versioniId=3754 Notice the lack of nonsense and useful information being moved into notes. Tom Wickline twickl...@gmail.com 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 Margolenwine-de...@kievinfo.com 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: 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
