http://bugs.winehq.org/show_bug.cgi?id=33985
Bug #: 33985
Summary: Nokia Music Player: window decorations should not be
displayed in installer window
Product: Wine
Version: 1.6-rc4
Platform: x86-64
URL: http://nds1.nokia.com/files/support/nseries/phones/sof
tware/SetupOviPlayer.exe
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: frederic.delanoy(a)gmail.com
Classification: Unclassified
Created attachment 45154
--> http://bugs.winehq.org/attachment.cgi?id=45154
WinXP/wine-1.6-rc4-52-g9a0b434 side-by-side comparison
The windows decorations (here from XFCE 4.10) are present in Wine while they
aren't in native Windows.
See attached screenshot for a comparison
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33984
Bug #: 33984
Summary: Nokia Music Player: extraneous transparent gray border
in installer window
Product: Wine
Version: 1.6-rc4
Platform: x86-64
URL: http://nds1.nokia.com/files/support/nseries/phones/sof
tware/SetupOviPlayer.exe
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: frederic.delanoy(a)gmail.com
Classification: Unclassified
Created attachment 45152
--> http://bugs.winehq.org/attachment.cgi?id=45152
WinXP/wine-1.6-rc4-52-g9a0b434 side-by-side comparison
See attached screenshot for a comparison
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33027
Bug #: 33027
Summary: sPlan 7.0: text label not displayed entirely in popups
Product: Wine
Version: 1.5.24
Platform: x86-64
URL: http://www.abacom-online.de/demos/splan70(demo).exe
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: frederic.delanoy(a)gmail.com
Classification: Unclassified
Install the demo version of sPlan 7.0, and start the program
You should see a "sPlan" popup containing:
"This is a limited sPlan 7.0 demo
Saving, exporting and printing is disabled."
The popup is present, but the "disabled." part is not displayed.
A similar issue occurs when you exit the program.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42756
Bug ID: 42756
Summary: test.winehq.org uses a lot of disk space
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
According to my estimates the static HTML files for the test.winehq.org site
use around 21.5 GB. That seems a lot for such a simple website.
This estimate is based on the following data collected from 3 days worth of
reports:
8.3MB / report
60 reports / day
500MB / day
44 days history
-> 21.5 GB total
It's not because the raw reports are big either. On any given day we get:
50 MB of raw report files
180 MB of full report HTML files
285 MB of individual test unit HTML files
3 MB of index files
So most of it is caused by the HTML files.
Here are some ways one could minimize the bloat:
1) Split the raw report into one file per test unit plus one index file to know
in which order to reassemble them. These would not use more space than the
original raw report except for the filesystem's internal fragmentation. Then
each file the web server serves would be generated from these. For the raw
report one would just have to concatenate them in the right order. The full
report and the individual test unit files would have to parse the relevant
source text files. A drawback is all the extra parsing required to generate
each page. Plus some issues in the raw report can only be detected when parsing
the full report as they show up as issue transitioning from one test result to
the next.
2) An other option would be to skip generating the full report HTML file and
omit the header and footer of the individual test unit HTML files. Then each
page could be generated by assembling the individual HTML fragments with the
right HTML glue to build either a full HTML report or an individual test unit
HTML file. This would have the advantage of not requiring more parsing to serve
each file.
3) Drop the individual test unit HTML files and always link to the full HTML
report. The drawback is more bandwidth usage since every one looking at a test
result would end up downloading the 180 MB full report instead of the small
individual test unit reports.
4) Drop the full HTML report and only keep the per test unit HTML files. This
provides a lower disk saving but does not force users to download a big file
when they are only interested in the result of one test unit.
5) Use some way to reduce the size of the links to the Git source. Removing the
links altogether saves 191 MB in the test case. Out of the 128 characters of a
typical link, 95 of these are identical from one link to the next. So maybe
using some JavaScript one could factorize most of this.
A drawback of options 1 and 2 is that since the files would no longer be static
they could probably not be put up on a content distribution network. But I'm
not sure test.winehq.org uses a CDN now so this probably does not matter.
It may still be possible to reduce the processing load introduced by 1 and 2 by
caching the generated files for a few hours or days. All in all this would
increase complexity quite a bit though.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42758
Bug ID: 42758
Summary: test.winehq.org: Provide stats on the tests output
size
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The Wine test reports are pretty close to the 1.5 MB limit so having an idea of
which the biggest offenders are would be helpful.
test.winehq.org could easily extract this data while parsing the reports and
then generate some per-build index files showing the test units sorted based on
how much they spammed the report.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42757
Bug ID: 42757
Summary: test.winehq.org: Provide stats on the tests run time
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
It would be interesting to have some information about where WineTest.exe
spends the most time as it sometimes takes close to 20 minutes (the maximum
allowed on the TestBot is 30 minutes so there is still some margin).
Having data on how long a test unit takes per platform could be valuable. This
would help identify which test units take too much time or which machines are
having trouble keeping up compared to their peers.
The WineTest reports contain run time data for each test unit with a 1s
granularity. This could be exploited to generate some extra per-build index
files showing the test units sorted by run time with some min, max and average
data.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38877
Bug ID: 38877
Summary: Ancestry Family Tree Maker 2014 on Wine1.6 Ubu14.04
Fails To Pass SN entry
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: loader
Assignee: wine-bugs(a)winehq.org
Reporter: jcjackson(a)joe-jackson.net
Distribution: ---
Ancestry Family Tree Maker 2014 on Wine1.6 Ubu14.04 Fails To Pass the Serial
Number Entry security pop-up, where the same install works properly on a
Windows partition on the same machine.
The Wine install worked without problem, and components like Notepad work as
expected, and the FTM install process starts as expected and seems to run well
up to the presentation of the security pop-up requesting the software serial
number, the error it throws is "Error Activating License! The requested feature
is not implemented. Please try again or visit our support site for help."
Retries do not work at all either. It is as if there is no network connection,
but the network features are working fine for other Ubu apps, and the install
works well on the Windows partition on the same machine.
One additional point, before winetricks would install 7-zip the permissions for
the .wine directory required normalization, .wine installed with just use
permissions for my user id without my group.
So few people use FTM there seems to be little chatter anywhere about the
install problems, most users seem to give up in 2009 and worked around by using
a Windows VM.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17063
Summary: Test results page should distinguish between 32-bit and
64-bit
Product: WineHQ.org
Version: unspecified
Platform: All
URL: http://test.winehq.org/data
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: www-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Looking at http://test.winehq.org/data, it's hard to find x86-64 test results
(wine or windows). We should probably separate them out into their own column
next to the 32-bit OS, e.g.:
Win2k3 WinXP-32bit WinXP-64bit ... Wine-32bit Wine-64bit
We've got Platform under the report info that shows if it's x86 or x86_64, so
extending tools/winetest/dissect to account for this shouldn't be too much
trouble for a perl guru.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36198
Bug ID: 36198
Summary: winetest reports now starting to exceed 1.5MB limit
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: testcases
Assignee: wine-bugs(a)winehq.org
Reporter: alasdairsinc(a)gmail.com
some of my winetest submissions are running into the 1.5MB limit that is
currently enforced by winetest, the win32 and wow64 ones are the worst.
When slightly over we get parial submissions like my wow64 in
http://test.winehq.org/data/b84e112dd60e9fb6f4d04e82115fcb46e71f9693/index_….
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42689
Bug ID: 42689
Summary: ACDSee Pro 10 won't launch the main UI
Product: Wine
Version: 2.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: spleefer90(a)gmail.com
Distribution: ---
Created attachment 57653
--> https://bugs.winehq.org/attachment.cgi?id=57653
main UI launch log
The program launches into tray, but opening it from there only shows up the
"launching UI" which then promptly disappears.
Logs from that attached.
Tested with recent wine-git
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.