http://bugs.winehq.org/show_bug.cgi?id=7461
truiken(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mike(a)codeweavers.com
Component|wine-kernel |wine-msi
------- Additional Comments From truiken(a)gmail.com 2007-21-02 13:11 -------
My analysis about OpenEvent is wrong. The following patch causes this regression:
63e554994a8c6cabf13751d0e1f0f686fcd61bd3 is first bad commit
commit 63e554994a8c6cabf13751d0e1f0f686fcd61bd3
Author: Mike McCormack <mike(a)codeweavers.com>
Date: Mon Feb 12 11:31:41 2007 +0900
msi: Store dll based custom actions in a separate list.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7211
------- Additional Comments From adam(a)tpetaccia.com 2007-21-02 12:50 -------
This happens more and more infrequently with each WINE release, with 0.9.30 I
haven't gotten one. But I get the exact same symptoms if I minimize Guild Wars.
Making it rather difficult to unminimize.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4961
adam(a)tpetaccia.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
------- Additional Comments From adam(a)tpetaccia.com 2007-21-02 12:48 -------
It works for me now; It was probably an invalid setup I had going at one point.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7511
Summary: Guildwars crashes with assersion failure
Product: Wine
Version: 0.9.30.
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: adam(a)tpetaccia.com
Using the opengl backend, Guild Wars crashes (or technically infinately hangs)
with the following:
glx_texture_compression.c:58: __indirect_glGetCompressedTexImageARB: Assertion
`image_bytes >= ((4 * reply.length) - 3)' failed.
This occurs in under two minutes of game play, with both the alpha mouse patch,
and lighting 'fix' applied (without these, the game is unplayable, or crashes
anyway). This is on an nVidia card; When played on an laptop with an Intel
card, I have yet to encounter this problem.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7510
thestig(a)google.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
Keywords| |download, Installer
------- Additional Comments From thestig(a)google.com 2007-21-02 12:39 -------
what's missing in the partial install?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=50
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From fgouget(a)codeweavers.com 2007-21-02 11:59 -------
Yay! It works great now.
Thanks for the conformance test and patch Pedro.
I'm marking the bug as closed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7295
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From fgouget(a)codeweavers.com 2007-21-02 11:54 -------
I have used two sources to update Wine's timezone data:
* Olson's timezone database
http://www.twinsun.com/tz/tz-link.htm
This seems to be the authoritative source of timezone data used by
the Glibc, Linux, FreeBSD, etc.
It can also be found online on Unicode.org's CLDR site:
http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/util/data/
* Unicode.org's Common Locale Data Repository (CLDR) Project's table
mapping from Windows timezone names to the Olson database timezone ids:
http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html
See the license in Exhibit 1 there:
http://www.unicode.org/copyright.html
Some notes:
* Wine uses the Olson tzid as the display name.
I have kept it that way as it seems to match what is displayed by Linux
distributions and tools. If we wanted we could use the following source
to get information more (/exactly) like the Windows display names:
http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/tool/Misc.ja…
* In many places we were using 'old tzids', that is timezone ids that Olson's
database only keeps around for backward compatibility. See the 'backward'
file in Olson's database:
http://unicode.org/cldr/repository/tools/java/org/unicode/cldr/util/data/ba…
So for those I switched to the new names.
* There are still some differences with the Windows timezone data. They are
detailed in a section below.
* For some Windows timezones we use a different Olson id than the one
specified by the CLDR database. These are detailed in a section below.
* Having done the mapping by hand once, I think it would be nice to be able
to automate the wine.inf update, especially as many countries seem to like
changing their daylight saving rules every year. Automation should be
feasible by combining the CLDR's mapping of Windows timezone names to
Olson tzids, and parsing the Olson database (which is complex but has
clearly been parsed before).
* If automated we could even automatically generate a very complete set of
registry values in Vista's new 'Dynamic DST' format.
* When comparing this data to the contents of the Windows XP registry, make
sure you have first applied the 'February 2007 cumulative time zone update
for Microsoft Windows operating systems' as it contains some important
fixes.
http://support.microsoft.com/?scid=kb%3Ben-us%3B931836&x=3&y=14
So here are the remaining differences with Windows. I hope that people can
analyze and pitch in on how best to handle them.
---
Differences in the TZI field
* Central Brazilian Standard Time - America/Manaus
Windows XP has DST settings for this timezone:
bias=240 / 0 / -60
- std=0000/00/00 (0) 00:00:00:0
- dst=0000/00/00 (0) 00:00:00:0
+ std=0000/02/05 (0) 00:00:00:0
+ dst=0000/11/01 (0) 00:00:00:0
* Egypt Standard Time - Africa/Cairo
Windows XP says Egypt switches to daylight saving time at 23:59:59 on the
last Thursday of April, while Olson say the switch is at 00:00:00 on the
last Friday of April. This looks like just a one second difference but
could widen to a whole week if the last Thursday of April is the last day
of April... So who's right?
bias=-120 / 0 / -60
std=0000/09/05 (4) 23:59:59:0
- dst=0000/04/05 (5) 00:00:00:0
+ dst=0000/04/05 (4) 23:59:59:0
* Greenland Standard Time - America/Godthab
The Windows XP DST start date does not match Olson's.
bias=180 / 0 / -60
std=0000/10/05 (0) 02:00:00:0
- dst=0000/03/05 (0) 02:00:00:0
+ dst=0000/04/01 (0) 02:00:00:0
* Jordan Standard Time - Asia/Amman
The Windows XP DST end date does not match Olson's.
bias=-120 / 0 / -60
- std=0000/10/05 (5) 00:00:00:0
+ std=0000/09/05 (5) 01:00:00:0
dst=0000/03/05 (4) 00:00:00:0
* Mid-Atlantic Standard Time - Atlantic/Noronha
Windows XP has DST settings for this timezone:
bias=120 / 0 / -60
- std=0000/00/00 (0) 00:00:00:0
- dst=0000/00/00 (0) 00:00:00:0
+ std=0000/09/05 (0) 02:00:00:0
+ dst=0000/03/05 (0) 02:00:00:0
* Middle East Standard Time
Again a difference of a few microseconds that would get as large as a week.
bias=-120 / 0 / -60
- std=0000/10/05 (0) 00:00:00:0
+ std=0000/10/05 (6) 23:59:59:999
dst=0000/03/05 (0) 00:00:00:0
* Namibia Standard Time - Africa/Windhoek
Windows XP says this is GMT+02:00 but Olson says it's GMT+01:00.
Windows XP also seems to have the DST dates reversed
(Namibia is in the southern hemisphere).
- bias=-60 / 0 / -60
- std=0000/04/01 (0) 02:00:00:0
- dst=0000/09/01 (0) 02:00:00:0
+ bias=-120 / 0 / 60
+ std=0000/09/01 (0) 02:00:00:0
+ dst=0000/04/01 (0) 02:00:00:0
* Pacific SA Standard Time
Again a difference of a few microseconds that would get as large as a week.
bias=240 / 0 / -60
- std=0000/03/02 (0) 00:00:00:0
- dst=0000/10/02 (0) 00:00:00:0
+ std=0000/03/02 (6) 23:59:59:999
+ dst=0000/10/02 (6) 23:59:59:999
---
Windows -> Tzid mapping differences to the CLDR
* Azerbaijan Standard Time -> Asia/Baku
Central Brazilian Standard Time -> America/Manaus
Georgian Standard Time -> Asia/Tbilisi
Jordan Standard Time -> Asia/Amman
Namibia Standard Time -> Africa/Windhoek
Middle East Standard Time -> Asia/Beirut
Montevideo Standard Time -> America/Montevideo
The CLDR is missing mappings for all of these. I reported it in CLDR bug
1282:
http://www.unicode.org/cldr/bugs/locale-bugs
* Central Standard Time (Mexico)
Mountain Standard Time (Mexico)
Pacific Standard Time (Mexico)
These are new too so the CLDR does not have a mapping for them either.
Further complicating the matter, they are copies of the old non '(Mexico)'
suffixed timezones and thus should have a different display name to
distinguish them.
* Caucasus Standard Time
Wine: Asia/Yerevan
CLDR: Asia/Tbilisi
Windows now has the '' which maps to 'Asia/Tbilisi' and this one seems to
more closely correspond to 'Asia/Yerevan'. See also bug 1282.
* Central America Standard Time
Wine: America/Regina
CLDR: America/Managua
Central Pacific Standard Time
Wine: Pacific/Guadalcanal
CLDR: Asia/Magadan
GTB Standard Time
Wine: Europe/Athens
CLDR: Europe/Istanbul
I'm unconvinced by the CLDR mappings for these so I'm essentially sticking
with Wine's existing mapping (but with the current Olson tzids).
* Dateline Standard Time
Wine: Pacific/Kwajalein
CLDR: Etc/GMT+12
I'm siding with CLDR bug 988 on this one.
* SA Eastern Standard Time
Wine: America/Argentina/Buenos_Aires
CLDR: America/Buenos_Aires
US Eastern Standard Time
Wine: America/Indiana/Indianapolis
CLDR: America/Indianapolis
The CLDR uses the old Olson timezone ids for these. Reported as CLDR bug
1283.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7510
Summary: Super Copyright (free software) fails to install and run
Product: Wine
Version: 0.9.30.
Platform: PC
URL: http://www.erightsoft.com/home.html
OS/Version: other
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bryan.christ(a)gmail.com
Super Copyright build v2007.bld.21 (January 4, 2007) installs only partially.
Because installation does not complete, application does not run.
Super Copyright is free software and can be downloaded at no charge from the URL
above.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7454
------- Additional Comments From truiken(a)gmail.com 2007-21-02 11:34 -------
> trace:msi:copy_install_file Copying L"Z:\\home\\zusatz\\Office
2000\\Windows\\Fonts\\TAHOMA.TTF" to L"c:\\windows\\Fonts\\TAHOMA.TTF"
> trace:msi:copy_install_file copy error: 5
5 is ERROR_ACCESS_DENIED. What are the permissions on TAHOMA.TTF in your
home/zusatz/Office... directory?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.