http://bugs.winehq.org/show_bug.cgi?id=35756
Bug ID: 35756
Summary: Bugzilla robots.txt prevents google indexing
Product: WineHQ Bugzilla
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: bugzilla-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: adys.wh(a)gmail.com
https://bugs.winehq.org/robots.txt
This is annoying as bugs cant be found through google.
--
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=56706
Bug ID: 56706
Summary: AppDB does not properly separate the Bugzilla DB
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jnewman(a)codeweavers.com
Distribution: ---
We would like to split the AppDB and Bugzilla databases onto different hosts.
But right now this is impossible due to some queries doing a joins between
bugzilla and the appdb.
These will need to be re-written to do it in a different way.
The worst offender is testData.php ShowVersionsTestingTable method on line 685.
I'm sure there are other places as well.
--
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=11787
Summary: Set mime type for log files are text/plain
Product: WineHQ Bugzilla
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: minor
Priority: P2
Component: bugzilla-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: thestig(a)google.com
Right now whenever someone attaches a .log file, Bugzilla auto-detects the mime
type as text/x-log. Many web browsers are set to download files with that mime
type, rather than just opening the file in the web browser. This is rather
annoying.
Can we change the mime types for .log files to text/plain instead? I believe
the code is in Bugzilla/Attachment.pm.
--
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=19561
Summary: Very large memory leak when doing overlapped reads
Product: Wine
Version: 1.1.26
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wineserver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ronfischler(a)gmail.com
Created an attachment (id=22796)
--> (http://bugs.winehq.org/attachment.cgi?id=22796)
Program compiled and ready to run using mingw
WINE is buffering serial ports which is in conflict with using overlapped
reads. Additionally, when using overlapped reads on a serial port, there is a
large memory leak. Every time we receive a block of data on the port, (say 800
bytes in our case,) wineserver allocates many pages on the heap and does not
free them afterwards. We are seeing as many as 21 pages lost to the heap every
time we read a small block of data.
My company is creating a Monitor & Control product that works through serial
ports, and we want it to be able to run on Linux netbooks (using USB to serial
port adapters.) This memory leak is the only thing holding us up. The memory
leak is too large for us to recommend to customers that our application can be
used on Linux platforms using WINE.
We are including an attachment for a small program that captures the leak. The
problem is a result of our call to readfile() in the do-while loop. It is using
the overlappedRead feature. Every time this Win32 function call is made, 84K
bytes disappears forever.
-Ron F.
--
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=38337
Bug ID: 38337
Summary: clang compiling warnings
Product: Wine
Version: 1.7.39
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: isakov-sl(a)bk.ru
Distribution: ---
Wine1.7.39-251-gdbf8bde compiled by Apple's clang. The wine works somehow.
There are hundreds warning so I show them in one bug although there are many
possible bugs.
----
keyboard.c:287:2: warning: illegal character encoding in string literal
[-Winvalid-source-encoding]
"?","&1","?2","\"3","'4","(5","-6","?7","_8","?9","?0",")?","=+",
^
----
cocoa_status_item.m:100:13: warning: instance method
'-discardEventsPassingTest:'
not found (return type defaults to 'id')
[queue discardEventsPassingTest:^BOOL (macdrv_event* event){
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
----
imgfactory.c:715:88: warning: implicit conversion from enumeration type
'WICBitmapAlphaChannelOption' (aka 'enum WICBitmapAlphaChannelOption') to
different enumeration type 'WICBitmapCreateCacheOption' (aka 'enum
WICBitmapCreateCacheOption') [-Wconversion]
...BitmapImpl_Create(bm.bmWidth, bm.bmHeight, bm.bmWidthBytes, 0, NULL,
&format, option,...
~~~~~~~~~~~~~~~~~
^~~~~~
-----
display.c:225:24: warning: unused function 'create_mode_dict'
[-Wunused-function]
static CFDictionaryRef create_mode_dict(CGDisplayModeRef display_mode)
^
1 warning generated.
-----
node.c:1620:37: warning: implicit conversion from enumeration type
'xmlElementType' to different enumeration type 'DOMNodeType' (aka
'enum tagDOMNodeType') [-Wconversion]
*domNodeType = This->node.node->type;
~ ~~~~~~~~~~~~~~~~~^~~~
1 warning generated.
-----
locale.c:11344:13: warning: unknown attribute '__force_align_arg_pointer__'
ignored [-Wattributes]
call_locale_facet_vector_dtor(iter->fac, 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
locale.c:246:52: note: expanded from macro 'call_locale_facet_vector_dtor'
#define call_locale_facet_vector_dtor(this, flags) CALL_VTBL_FUNC(this, 0, \
^
./cxx.h:269:59: note: expanded from macro 'CALL_VTBL_FUNC'
#define CALL_VTBL_FUNC(this, off, ret, type, args) ((ret (WINAPI*...
^
../../include/windef.h:169:21: note: expanded from macro 'WINAPI'
#define WINAPI __stdcall
^
../../include/msvcrt/crtdefs.h:48:67: note: expanded from macro '__stdcall'
...__attribute__((__stdcall__)) __attribute__((__force_align_arg_pointer__))
^~~~~~~~~~~~~~~~~~~~~~~~~~~
-----
mach.c:93:9: warning: 'bootstrap_register' is deprecated
[-Wdeprecated-declarations]
if (bootstrap_register(bp, (char*)wine_get_server_dir(), ...
^
----
warning: Small Fonts 11: missing glyph for char 05b0
----
file.c:2124:49: warning: array index 1 is past the end of the array
(which contains 1 element) [-Warray-bounds]
dir_info->FileName[0] == '.' && dir_info->FileName[1] == ...
^ ~
../../include/winternl.h:495:5: note: array 'FileName' declared here
WCHAR FileName[ANYSIZE_ARRAY];
^
1 warning generated.
----
I omitted same warnings repeated many times.
--
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=57204
Bug ID: 57204
Summary: after enable winedmo, Little Witch Nobeta video wont
play anymore
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: l12436.tw(a)gmail.com
Distribution: ---
Created attachment 77101
--> https://bugs.winehq.org/attachment.cgi?id=77101
Log under Little Witch Nobeta
After enable winedmo. the Little Witch Nobeta wont play video anymore
It normal under winegstreamer.
--
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=57244
Bug ID: 57244
Summary: Train capacity 300% 2 will crash after enable the
winedmo
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: l12436.tw(a)gmail.com
Distribution: ---
Created attachment 77161
--> https://bugs.winehq.org/attachment.cgi?id=77161
Detail log from Train capacity 300% 2
Also video regression due to winedmo.
Game will crash at the title video or gallery video
--
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=58263
Bug ID: 58263
Summary: Wine Internet Settings crashes on unimplemented
function shdocvw.dll.ParseURLFromOutsideSourceW
Product: Wine
Version: 10.2
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: shdocvw
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
Created attachment 78602
--> http://bugs.winehq.org/attachment.cgi?id=78602
Backtrace
Steps to reproduce:
1. Run `wine control inetcpl.cpl`
2. Click "OK" (not "Cancel")
Wine prints the following and crashes:
wine: Call from 00006FFFFF3FCFC7 to unimplemented function
shdocvw.dll.ParseURLFromOutsideSourceW, aborting
wine: Unimplemented function shdocvw.dll.ParseURLFromOutsideSourceW called at
address 00006FFFFF3FCFC7 (thread 0148), starting debugger...
0150:fixme:dbghelp:elf_search_auxv can't find symbol in module
0150:fixme:dbghelp:elf_search_auxv can't find symbol in module
wine: Call from 00006FFFFF3FCFC7 to unimplemented function
shdocvw.dll.ParseURLFromOutsideSourceW, aborting
ParseURLFromOutsideSourceW is called from the parse_url_from_outside function
in dlls/inetcpl.cpl/general.c:
https://gitlab.winehq.org/wine/wine/-/blob/8f91df4c4e4fb8b32c737bb02e82dcdd…
It used to work fine before ParseURLFromOutsideSourceW was removed in
https://gitlab.winehq.org/wine/wine/-/commit/fa4a470f9afd79b8104bacf3f1046e…
--
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=57790
Bug ID: 57790
Summary: FindVUK doesn't show drive details
Product: Wine
Version: 10.0
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
Even when there is a blu-ray disc in the drive, `wine FindVUK.exe
showdrivedetails` prints the error "Cannot enumerate storage device - stop
getting drive details for this drive". It also writes a log file which contains
the more specific message "IOCTL_STORAGE_QUERY_PROPERTY 1 failed with error
code 0".
Some debugging revealed that there are two problems: First,
IOCTL_STORAGE_QUERY_PROPERTY(StorageDeviceProperty) is not implemented, and
second, IOCTL_DISK_GET_MEDIA_TYPES always returns FILE_DEVICE_CD_ROM as opposed
to FILE_DEVICE_DVD.
$ sha256sum FindVUK_1.79.zip
39e954675855da3826256448b2a6b851c9478dda03c5d32bbfe4a3bac37ca623
--
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=52720
Bug ID: 52720
Summary: cmd.exe:batch times out in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
cmd.exe:batch started timing out in Wine on 2022-03-17:
batch.c:427: running TEST_CMDLINE.CMD test...
cmd.exe:batch:040c done (258) in 120s
Test failed: timed out
https://test.winehq.org/data/patterns.html#cmd.exe:batch
Unfortunately I was unable to find a change in Wine that would be the cause for
the timeout: in my tests cmd.exe:batch still times out when run from older Wine
versions.
* Based on the WineTest logs cmd.exe:batch was taking about 50 seconds up to
2022-03-16. But the next day that run time more than doubled to about 118 - 170
seconds, causing it to time out most of the time.
* Reverting the Wine source to the 2022-03-16 head, rebuilding from scratch and
recreating the wineprefix did not help: cmd.exe:batch still times out.
* No package upgrades were performed on that date. Plus this regression
happened simultaneously on multiple machines with different upgrade schedules.
* WINETEST_TIME=1 indicates that almost all of the time is spent running
TEST_BUILTINS.CMD:
batch.c:427:0.149 running TEST_BUILTINS.CMD test...
batch.c:136:158.289 Test succeeded
^^^ The first ok() call after WaitForSingleObject() is in the map_file() called
after run_test()
* Running the test manually it looked like the "--- for /R" "Plain directory
enumeration" part of test_builtins.cmd was enumerating all of the computer's
directories, starting with /bin, /boot, /etc, ... That would certainly take a
long time but that run crashed after about 1 minute so this may be unrelated.
--
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.