https://bugs.winehq.org/show_bug.cgi?id=56707
Bug ID: 56707
Summary: AppDB PHP8 rewrite
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: ---
The current codebase is not compatible with PHP8. We are stuck on 7.4.
The main issue is how all the objects are setup. PHP8 requires you define a
constructor as __construct, but the AppDB is using the old method of naming the
constructor the same as the object itself. While you could just rename all
those to __construct, there are places in the objects where the code refers to
$this->className(), these would need to be changed to $this->__construct() or
parent::__construct if called from a child class
There are other PHP8 issues to be solved as well. Things like some built in
functions changing how the null type is handled.
--
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=58307
Bug ID: 58307
Summary: Cannot delete bug link
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: download, source
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: imwellcushtymelike(a)gmail.com
Distribution: ---
Ooops! Something has gone terribly wrong!
Our monkey train has derailed! Worry not, a webmaster gopher help army has been
dispatched and is on the way.
If this error continues to be a problem, please report it to us on our Forums
error details:
Error Message: Uncaught Error: Non-static method error_log::log_error() cannot
be called statically in /home/winehq/opt/appdb/include/objectManager.php:1470
Stack trace: #0 /home/winehq/opt/appdb/objectManager.php(81):
ObjectManager->processForm() #1 {main} thrown
File: objectManager.php:1470
--
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=57844
Bug ID: 57844
Summary: Cannot submit new app version due to being blocked by
cloudflare.
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: topgamer7(a)gmail.com
Distribution: ArchLinux
Created attachment 78062
--> https://bugs.winehq.org/attachment.cgi?id=78062
page I was redirected to
When I go and fill out a new version for some software (StudioTax), I get
through filling out the questionnaire, and then when I submit, I get blocked by
cloudflare.
Particularly infuriating because you lose all progress in what you submitted.
--
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=57741
Bug ID: 57741
Summary: WineHQ AppDB Create Account create accout
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: tin.strunjak(a)gmail.com
Created attachment 77938
--> https://bugs.winehq.org/attachment.cgi?id=77938
error while trying to create a new account
I am trying to create an account on the whineHQ AppDB via
https://appdb.winehq.org/account.php?sCmd=new
However, when I populate required fields and click on create account I get this
error screen related to CAPTCHA (even though it is verified).
Thanks
forum topic: https://forum.winehq.org/viewtopic.php?t=40167
--
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=57151
Bug ID: 57151
Summary: AppDB is incredibly slow
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: source
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: imwellcushtymelike(a)gmail.com
Distribution: ---
The AppDB seems to be getting slower and slower. Today it's taking up to a
minute just to load a page. Does it need more resources?
--
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=56738
Bug ID: 56738
Summary: ODBC stopped working in Wine 9.9, it works fine in 9.8
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: odbc
Assignee: wine-bugs(a)winehq.org
Reporter: claudius+wine(a)hausnetz.lettenbach.com
Distribution: ---
Created attachment 76517
--> https://bugs.winehq.org/attachment.cgi?id=76517
WINEDEBUG logs
After updating my Arch linux install from wine 9.8-2 to wine 9.9-2 my 32bit
applications using multilib unixodbc stopped working.
I tried WINEDEBUG=+odbc but could get much relevant output.
Most interesting is probabaly this: trace:odbc:SQLAllocEnv Returning 309,
EnvironmentHandle 00000000
WINEDLLOVERRIDES="odbc32=b" or "odbc=b" didn't change anything as far as I can
tell.
If I downgrade the package it immediately starts connecting again.
The driver I use is the proprietary SQL Anywhere 17 odbc driver.
It works fine using unixodbc with both linux x86_64 and linux 32 bit
applications.
Is there any way I can provide more relevant information?
Attached is a trace of +odbc when it works, and when it doesn't.
--
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=58460
Bug ID: 58460
Summary: Application crashes when you run on generic video
adapter
Product: Wine
Version: 10.11
Hardware: x86-64
OS: Windows
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: svyatpro(a)gmail.com
For example you run Firefox on Windows with WineD3D and you have basic VBOX
graphics adapter.
096c:trace:d3d:wined3d_init Initialising adapters.
096c:trace:d3d:wined3d_adapter_gl_init adapter_gl 17DAD470, ordinal 0,
wined3d_creation_flags 0.
096c:trace:d3d:wined3d_adapter_init adapter 17DAD470 LUID 00000000:00044065.
096c:trace:d3d:wined3d_output_init output 17D84DE0, device_name
L"\\\\.\\DISPLAY1".
096c:trace:d3d:wined3d_adapter_create_output Initialised output
L"\\\\.\\DISPLAY1".
096c:trace:d3d:wined3d_adapter_init Initialised 1 outputs for adapter 17DAD470.
096c:trace:d3d:wined3d_caps_gl_ctx_create getting context...
096c:trace:d3d:wined3d_adapter_init_gl_caps adapter_gl 17DAD470.
096c:trace:d3d:wined3d_adapter_init_gl_caps GL_RENDERER: "GDI Generic".
096c:trace:d3d:wined3d_adapter_init_gl_caps GL_VENDOR: "Microsoft Corporation".
096c:trace:d3d:wined3d_adapter_init_gl_caps GL_VERSION: "1.1.0".
096c:trace:d3d:wined3d_parse_gl_version Found OpenGL version 1.1.
096c:trace:d3d:wined3d_adapter_init_gl_caps GL extensions reported:
96c:trace:d3d:parse_extension_string - "GL_WIN_swap_hint".
096c:trace:d3d:parse_extension_string - "GL_EXT_bgra".
096c:trace:d3d:parse_extension_string - "GL_EXT_paletted_texture".
096c:warn:d3d:wined3d_adapter_init_gl_caps WGL extensions not supported.
096c:trace:d3d:wined3d_adapter_init_limits Clip plane support - max planes 6.
096c:trace:d3d:wined3d_adapter_init_limits Light support - max lights 8.
096c:trace:d3d:wined3d_adapter_init_limits Maximum texture size support - max
texture size 1024.
096c:trace:d3d:wined3d_check_gl_call extension detection call ok
../wine-src-copy/dlls/wined3d/adapter_gl.c / 3691.
096c:fixme:d3d:wined3d_guess_gl_vendor Received unrecognized GL_VENDOR
"Microsoft Corporation". Returning GL_VENDOR_UNKNOWN.
096c:trace:d3d:wined3d_adapter_init_gl_caps Guessed GL vendor 0.
096c:trace:d3d_shader:shader_glsl_get_caps Shader model 2.
096c:fixme:d3d:wined3d_guess_card_vendor Received unrecognized GL_VENDOR
"Microsoft Corporation". Returning HW_VENDOR_NVIDIA.
096c:trace:d3d:wined3d_adapter_init_gl_caps Guessed vendor PCI ID 0x10de.
096c:trace:d3d:wined3d_guess_card Applying card selector "NVIDIA".
096c:fixme:d3d:select_card_handler Couldn't find a suitable card selector for
GL vendor 0000 (using GL_RENDERER "GDI Generic")
096c:trace:d3d:wined3d_guess_card Unrecognized renderer "GDI Generic", falling
back to default.
096c:trace:d3d:wined3d_adapter_init_gl_caps Guessed device PCI ID 0x0100.
096c:err:d3d:wined3d_check_gl_call >>>>>>> GL_INVALID_ENUM (0x500) from
glTexImage2D @ ../wine-src-copy/dlls/wined3d/adapter_gl.c / 641.
--
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=58465
Bug ID: 58465
Summary: Wide string misbehavior on C++20 mode vs C++17 mode
Product: Wine
Version: 10.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winelib
Assignee: wine-bugs(a)winehq.org
Reporter: messmer.dalton(a)gmail.com
Distribution: ---
Created attachment 78920
--> http://bugs.winehq.org/attachment.cgi?id=78920
Simple Winelib program to demonstate the bug (wine_test.cpp) + build/run script
(wine_test.sh) + my test results (output.txt)
When I compile a Winelib application using the `--std=c++20` wineg++ flag
instead of `--std=c++17`, I experience unexpected differences in behavior when
using `std::wstring`. And in both C++ modes the behavior is incorrect.
For example, when I call the `c_str()` method on `std::wstring` and pass the
returned wide C-string to `std::wcslen`, I get different results depending on
whether the Winelib application was compiled in C++20 mode vs C++17 mode. And
in both cases, the reported string length is incorrect.
Also, the distance between the `begin()` and `end()` iterators is different
between C++ modes, and so is the return value of the `length()` method. And all
of the results are incorrect in general.
I originally noticed these `std::wstring` problems here:
https://github.com/LMMS/lmms/pull/7624#issuecomment-2923573719
I've attached a simple Winelib program that demonstrates the bug to this bug
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.