August 2026 - Wine-Bugs - list.winehq.org

[Bug 56659] New: Total War Shogun 2 doesn't render 3D model textures in D3D11 mode.
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=56659 Bug ID: 56659 Summary: Total War Shogun 2 doesn't render 3D model textures in D3D11 mode. Product: Wine Version: 9.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Created attachment 76434 --> https://bugs.winehq.org/attachment.cgi?id=76434 Console log in D3D11 mode. Now that bug #53197 is fixed, the game actually gets in game with wine's builtin D3D11. However, none of the game's 3D model textures render at all. With all 3D models appearing with a solid black / dark grey color. In addition some effects are also missing. Such as the cherry blossoms and leaves on the trees. The result is a very burnt out / heavy fog looking Japan. As seen in the attached screenshots. As bug #53197 was about stubbing D3DX11LoadTextureFromTexture() in wine, it may be related. Finally, attempting to enter a battle from the campaign map will cause the game to crash after a few calls to D3DX11GetImageInfoFromMemory(). Console log attached. -- 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.

2 9

[Bug 56628] New: Golftopia (GOG) crashes during startup in unityplayer on Intel iGPU.
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=56628 Bug ID: 56628 Summary: Golftopia (GOG) crashes during startup in unityplayer on Intel iGPU. Product: Wine Version: 9.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Created attachment 76403 --> https://bugs.winehq.org/attachment.cgi?id=76403 Crash backtrace Attempting to run Golftopia with an Intel iGPU (Intel Corporation Device [8086:0a1e] (rev 0b)) causes the game to crash during startup after the initial loading dialog. Backtrace attached. -- 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.

2 14

[Bug 59976] New: Maximized windows cover the taskbar when using virtual desktop (explorer /desktop=shell)
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59976 Bug ID: 59976 Summary: Maximized windows cover the taskbar when using virtual desktop (explorer /desktop=shell) Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)list.winehq.org Reporter: ajf(a)ajf.me Target Milestone: --- Distribution: --- Created attachment 81374 --> http://bugs.winehq.org/attachment.cgi?id=81374 explorer /desktop=shell,640x480 with maximized Notepad window (taskbar can't be seen because it is covered by the maximized window) With an invocation like `wine explorer /desktop=shell,640x480`, WINE will open a virtual desktop with a taskbar provided by explorer.exe. If I launch a program in this environment, for example notepad.exe, it covers the entire desktop *including* the taskbar, meaning that the taskbar becomes hidden and therefore inaccessible. This is not what you would expect. This happens with WINE 10.0 stable, WINE 11.0 stable, and the latest WINE master. I haven't tested any other versions. -- 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.

1 9

[Bug 60189] New: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version)
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60189 Bug ID: 60189 Summary: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: fcasas(a)codeweavers.com Target Milestone: --- Distribution: --- Created attachment 81874 --> http://bugs.winehq.org/attachment.cgi?id=81874 Screenshot with highlighted artifacts. Recent upstream vkd3d-shader updates allow the game shaders to compile correctly. However I noticed that updating Wine itself (on a Wine with custom vkd3d build) introduces small, previously unseen, visual artifacts. These artifacts consist in some flickering black stains that can be easily seen in the characters in the intro animation. They are easier to spot in motion but I attach a screenshot highlighting them. I ran a bisection and concluded that this bug is introduced in commit 306c3af83faca8bd384df24d370a863cab5ed394 d3dx9: No longer prefer native. So it might be considered a regression. -- 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.

1 5

[Bug 60193] New: wineconsole: ReadConsoleInputW never delivers a KEY_DOWN record for non-Latin (Cyrillic) keyboard-layout keys, only KEY_UP
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60193 Bug ID: 60193 Summary: wineconsole: ReadConsoleInputW never delivers a KEY_DOWN record for non-Latin (Cyrillic) keyboard-layout keys, only KEY_UP Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: unxed(a)mail.ru Target Milestone: --- Distribution: --- Component: console Version: (fill in actual `wine --version`, seen with a recent 11.x build) Summary: When the active keyboard layout is switched to a non-Latin one (Cyrillic, via Alt+Shift) inside a console application that reads raw input via ReadConsoleInputW, pressing a key that produces a Cyrillic character delivers only the KEY_UP input record for that key. The corresponding KEY_DOWN record is never generated/delivered at all -- not filtered by modifiers, not present with a zero character, simply absent. The same physical key, before switching layout (still Latin/US), delivers both KEY_DOWN and KEY_UP normally. Reproduction: 1. Run a console application under `wineconsole` (also reproduces under plain `wine app.exe` launched from a unix terminal) that logs every KEY_EVENT_RECORD it receives from ReadConsoleInputW/PeekConsoleInputW, including bKeyDown, wVirtualKeyCode, wVirtualScanCode, uChar, and dwControlKeyState. 2. Type a Latin letter, e.g. `f`. Confirm both KEY_DOWN and KEY_UP records are logged. 3. Switch the keyboard layout to Russian (Alt+Shift, or whatever the host is configured to use). 4. Type the Cyrillic letter on the same physical key (e.g. `ф`, which sits on the same key as Latin `a`, scan code 0x1E on a US-QWERTY board). Expected: a KEY_DOWN record with bKeyDown=TRUE, the Cyrillic character in uChar, followed by a matching KEY_UP record. Actual: no KEY_DOWN record appears at all for that keypress. Only a single KEY_UP record is delivered, with bKeyDown=FALSE and uChar=0 ('\0'). The application has no way to know a key was pressed until it's already released, and never receives the character. Example log excerpt (application-side, timestamps/PID prefix stripped): Key{VK:VK_MENU Scan:0x38 DOWN Mods:Alt} <- Alt down (layout switch chord) Key{VK:VK_MENU Scan:0x38 UP Mods:Shift} Key{VK:VK_SHIFT Scan:0x2A UP Mods:None} Key{VK:VK_A Scan:0x1E UP Mods:None} <- the "ф" key: KEY_UP only, no KEY_DOWN, Char=0 No KEY_DOWN for VK_A/scan 0x1E appears anywhere in the log before this KEY_UP, at any point since the previous, unrelated keypress. This was diagnosed by instrumenting the calling application at the very first point after ReadConsoleInputW returns (before any of the application's own filtering), so it is not the application dropping or misinterpreting an incoming DOWN event -- the DOWN event itself is not being produced/delivered by Wine's console input path for this key in this layout state. Environment where this was observed: - Host: Linux (Mint/Cinnamon, X11) and separately a second machine running a different distro -- reproduced on at least two independent setups. - Both `wineconsole app.exe` and `wine app.exe` (launched from a unix terminal, using the console's own window) show the same symptom. - Not observed for Latin-layout keys on the same host/session. Impact: any console application relying on ReadConsoleInputW for text entry cannot receive Cyrillic (and presumably other non-Latin-layout) character input at all under affected Wine versions/console frontends. Happy to attach a WINEDEBUG=+key,+keyboard trace and/or a minimal reproducer if useful -- ask and I'll provide it. -- 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.

1 3

[Bug 60191] New: winex11: Owned WS_EX_TOOLWINDOW popups are override-redirect and stay above other applications
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60191 Bug ID: 60191 Summary: winex11: Owned WS_EX_TOOLWINDOW popups are override-redirect and stay above other applications Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Urias.Uhle(a)web.de Target Milestone: --- Distribution: --- An owned WS_POPUP window with WS_EX_TOOLWINDOW is a palette. On Windows it stays above its owner but goes behind another application when that application is activated. is_window_managed() in dlls/winex11.drv/window.c returns FALSE for such a window, so Wine creates it override-redirect. The window manager never stacks it, and it floats above every other window on the desktop for as long as it exists. Reproduced with Autodesk Fusion, whose docked palettes are exactly this window class. Qt creates WS_POPUP | WS_EX_TOOLWINDOW; see !11415 for the same window class on the Wayland side, there without an owner. Managing owned tool window popups fixes it. Adding the rule as the last check in is_window_managed(), right before the default "return FALSE", keeps it free of side effects, because every window reaching that point is unmanaged in stock Wine. I measured that over a matrix of 25 top level windows covering 21 style, ex-style and owner combinations, reading back override-redirect, _NET_WM_WINDOW_TYPE and WM_TRANSIENT_FOR from the X server: exactly one row changes, the owned tool window, from unmanaged to managed. Two things that make it safe are already in place. get_mwm_decorations_for_style() returns 0 for WS_EX_TOOLWINDOW, so no title bar appears, and _NET_WM_STATE_SKIP_TASKBAR is already set for tool windows, so no taskbar entry appears. _NET_WM_WINDOW_TYPE_UTILITY would also be the correct type for these windows. EWMH defines it as "a small persistent utility window, such as a palette or toolbox". The atom is declared in Wine but never used; owned popups currently get the dialog type. Tested on GNOME with XWayland. I am not opening a merge request, because I worked this out with LLM assistance and the WineHQ contributor policies ask contributors to refrain from that. -- 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.

1 3

[Bug 60192] New: ntsync: lost wakeup causes permanent deadlock on infinite-timeout WAIT_ANY
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60192 Bug ID: 60192 Summary: ntsync: lost wakeup causes permanent deadlock on infinite-timeout WAIT_ANY Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: strikeralt40(a)gmail.com Target Milestone: --- Distribution: --- Summary Under heavy multi-threaded load, ntsync intermittently and permanently loses a wakeup for an infinite-timeout wait (NTSYNC_IOC_WAIT_ANY with timeout = U64_MAX). The waiter never wakes even though the event it waits on is set tens of thousands of times afterward. The task remains blocked in schedule_hrtimeout_range_clock() forever, deadlocking the entire application. Reproduced with Grand Theft Auto V (job-system synchronization) on kernel 7.1.8-1-cachyos. The same workload runs indefinitely with esync/fsync, and the same game runs indefinitely on ntsync once it gets past the freeze window, so the failure is a rare, intermittent lost-wakeup race, not a guaranteed bug. Environment - Kernel: 7.1.8-1-cachyos (CONFIG_NTSYNC=m, ntsync loaded, /dev/ntsync rw-rw-rw) - ntsync source: drivers/misc/ntsync.c, identical logic in v7.1 and current master (the only master difference is timens_ktime_to_host, which does not touch the sleep path) - Wine: cachyos-11.0 (Wine 11.0), 64-bit, NTSYNC_IOC_WAIT_ANY - Application: Grand Theft Auto V v1.69, job-system spawns dozens of worker threads - strace 7.0 attached to all GTA5.exe threads during a live freeze Reproduction Run GTA V (or any app that heavily uses ntsync events with infinite waits across many threads) under Wine with ntsync. The job system freezes at a random time — minutes to ~2 hours in. Symptoms at freeze: - Main thread spins forever in GTA5.exe+0x165F5B5 (job-sync spin loop) - Job counter frozen at 30 (0x1e) - Workers keep calling NTSYNC_IOC_EVENT_SET on the event the main thread waits on, but the main thread never wakes. The freeze is permanent (observed 30+ minutes). esync/fsync do not reproduce it. Trace evidence (215 MB strace capture, all GTA5.exe threads) Key ioctl counts during the freeze: ioctl count NTSYNC_IOC_EVENT_SET total 506,041 NTSYNC_IOC_EVENT_SET on fd 733 243,225 NTSYNC_IOC_WAIT_ANY issued 841,093 NTSYNC_IOC_WAIT_ANY still unfinished at capture 622,071 threads stuck in WAIT_ANY at capture end 694 The main thread's ioctl(10, NTSYNC_IOC_WAIT_ANY, ...) was issued once and never resumed (<unfinished ...> persists to end of capture), while fd 733 (a ntsync event) was set 243,225 times by worker threads. The signal was delivered to the kernel's wake path, but the waiter's wake_up_process() either raced with its schedule() or was absorbed, and the thread slept forever. Root-cause analysis ntsync_schedule() (drivers/misc/ntsync.c, both v7.1 and master): static int ntsync_schedule(const struct ntsync_q *q, const struct ntsync_wait_args *args) { ktime_t timeout = ns_to_ktime(args->timeout); clockid_t clock = CLOCK_MONOTONIC; ktime_t *timeout_ptr; int ret = 0; timeout_ptr = (args->timeout == U64_MAX ? NULL : &timeout); do { if (signal_pending(current)) { ret = -ERESTARTSYS; break; } set_current_state(TASK_INTERRUPTIBLE); if (atomic_read(&q->signaled) != -1) { ret = 0; break; } ret = schedule_hrtimeout_range_clock(timeout_ptr, 0, HRTIMER_MODE_ABS, clock); } while (ret < 0); __set_current_state(TASK_RUNNING); return ret; } The wake path (try_wake_any_event): if (atomic_try_cmpxchg(&q->signaled, &signaled, entry->index)) { if (!event->u.event.manual) event->u.event.signaled = false; wake_up_process(q->task); } For an infinite wait, timeout_ptr == NULL, so schedule_hrtimeout_range_clock(NULL, ...) is reached. In kernel/time/sleep_timeout.c: if (!expires) { schedule(); return -EINTR; } For the NULL (infinite) case, schedule_hrtimeout_range_clock() performs a plain, unconditional schedule() — it does not re-check the condition after waking, and more importantly it does not participate in the wakeup protocol the same way the non-NULL path does (hrtimer_sleeper_start_expires() + schedule() + hrtimer_cancel()). The racy window: 1. Waiter runs set_current_state(TASK_INTERRUPTIBLE), reads q->signaled == -1 (not yet signaled), is about to call schedule_hrtimeout_range_clock(NULL). 2. Waker wins atomic_try_cmpxchg(&q->signaled, -1, index), then calls wake_up_process(q->task). 3. The waiter is still on the runqueue at this point (it has not yet entered schedule()), so try_to_wake_up() takes the on_rq && ttwu_runnable() fast path in kernel/sched/core.c — it "wakes" the task without actually placing it on the runqueue, because it is already there. 4. The waiter then calls schedule(); with prev->state == TASK_INTERRUPTIBLE, __schedule() dequeues it and it sleeps. 5. q->signaled is now non--1, so every subsequent NTSYNC_IOC_EVENT_SET fails the atomic_try_cmpxchg(&q->signaled, -1, ...) and never calls wake_up_process() again. The wake is permanently lost. This exactly matches the trace: 243,225 EVENT_SET calls on the event, none of which can re-wake the thread, because the cmpxchg only succeeds once and the thread never consumes the signal. esync/fsync are immune because futex FUTEX_WAIT/FUTEX_WAKE and eventfd wakeup have stricter semantics than wake_up_process() on a task that has set_current_state(TASK_INTERRUPTIBLE) but has not yet called schedule(). Suggested fix directions 1. In ntsync_schedule(), for the infinite (timeout_ptr == NULL) case, use a loop that re-checks atomic_read(&q->signaled) after every schedule()/wakeup instead of relying on schedule_hrtimeout_range_clock() returning; and/or use wait_event_interruptible()-style semantics so that a condition satisfied before schedule() is observed after it. e.g. for timeout_ptr == NULL, replace with: while (!signal_pending(current) && atomic_read(&q->signaled) == -1) { set_current_state(TASK_INTERRUPTIBLE); if (atomic_read(&q->signaled) != -1) { ret = 0; break; } schedule(); } (which mirrors what wait_event_interruptible() does internally) so that a wakeup that "lands" before the task actually sleeps is not lost. 2. Alternatively, in the wake path, ensure that once q->signaled has been set, a subsequent wake_up_process() is issued even if the cmpxchg fails — i.e., make the wake resilient to the race by not gating the wake strictly on the cmpxchg winning. 3. Consider whether schedule_hrtimeout_range_clock(NULL) should be avoided in favor of an explicit bounded timeout converted from U64_MAX semantics, so the timer-based path (which handles spurious-wakeup correctly) is always used. Files inspected - drivers/misc/ntsync.c (v7.1.8 and master — identical sleep logic) - kernel/time/sleep_timeout.c (schedule_hrtimeout_range_clock, NULL/infinite path) - kernel/sched/core.c (try_to_wake_up, ttwu_runnable, __schedule) - strace capture /tmp/opencode/ntsync_trace.txt (215 MB, all GTA5.exe threads) Impact Any Windows app using ntsync events/mutexes with infinite waits under heavy multithreading can freeze permanently. This is not GTA-specific; GTA V is simply the test case that exercises the race often enough to observe it. The bug is present in current mainline ntsync (verified against master as of the report date). -- 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.

1 1

[Bug 60170] New: Emacs zoom not fully working for ASCII vs non-ASCII, unicode
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60170 Bug ID: 60170 Summary: Emacs zoom not fully working for ASCII vs non-ASCII, unicode Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs(a)list.winehq.org Reporter: wineryyyyy(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81810 --> http://bugs.winehq.org/attachment.cgi?id=81810 Screenshot GNU Emacs 30.2 zoom not fully working for wine-11.15-ab0b3e25268 `M-x view-hello-file` shows most non-ASCII supporting zoom but not ASCII. `M-x describe-char` provides more details about each of the characters: character: λ (displayed as λ) (codepoint 955, #o1673, #x3bb) charset: unicode (Unicode (ISO10646)) code point in charset: 0x03BB script: greek Most Emacs modes mostly deal with ASCII only especially for dev purposes so zoom is broken for some of the most common modes including: - Dired - org-mode - magit - c-mode - ibuffer - shell - info Some more edge modes like eww (web browser) and image viewer support zoom. Most Emacs users will probably just use native vs Windows via wine but whatever is bugged may affect other apps so it provides a reliable reproduction. I've used Emacs to test other text/font related bugs that are still an enigma so hopefully progress for this bug will lead to solutions for those others. -- 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.

1 16

[Bug 60186] New: Installing Mad Max [PC] causes the attached log errors.
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60186 Bug ID: 60186 Summary: Installing Mad Max [PC] causes the attached log errors. Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: asiedurichard213(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81869 --> http://bugs.winehq.org/attachment.cgi?id=81869 Mad max pc game installation error(Bottles) Mad Max setup crashing on installation(Bottles) -- 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.

1 1

[Bug 60100] New: AppDB migration to Content Management System
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60100 Bug ID: 60100 Summary: AppDB migration to Content Management System Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: wineryyyyy(a)gmail.com Target Milestone: --- Distribution: --- This is more an enhancement request than bug but may serve as a catch all for current AppDB bugs: - https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&b… AppDB repo celebrates it's 22th anniversary this year: 8f28ae10c40de0794a72fef07f7e05f1017cb691 Author: Jeremy Newman <jnewman(a)winehq.org> AuthorDate: Mon Mar 15 16:22:00 2004 +0000 Commit: Jeremy Newman <jnewman(a)winehq.org> CommitDate: Mon Mar 15 16:22:00 2004 +0000 In-house AppDB may have been a wiser decision in 2004 because many open source CMSs were still fairly early and perhaps less capable of serving AppDB needs but for 2026 it feels like a decision whether to use Bugzilla or Gitlab vs custom in-house solutions. Therefore this bug is for open discussion and feedback regarding migrating AppDB to one of many CMS solutions: - https://en.wikipedia.org/wiki/List_of_content_management_systems I have most dev exp. and expertise with Drupal and Moodle both written in PHP and supported by nearly identical software stack as AppDB. Moodle has an online demo available and Drupal offers a lesser convenient localhost demo that requires downloading: - https://sandbox51.moodledemo.net/login/index.php - https://www.drupal.org/project/drupaldemo Moodle is technically a Learning Management System (LMS) but may be used as a CMS just as Drupal may also be customized as an LMS via various plugin modules. Moodle has some builtin surveying/quiz features that may be useful for AppDB and better handled as an integral part vs as plugins by Drupal or other more generic CMSs. Customizing these CMSs from AppDB admins/maintainers experience should feel equivalent to that of Bugzilla and Gitlab which is largely supported via web-based UIs vs involving PHP or SQL changes often required for AppDB customizations. Source is still available when needed but changes overall should be rare like Bugzilla and Gitlab. CMSs would automatically fix many AppDB bugs including security vulnerabilities: - https://bugs.winehq.org/show_bug.cgi?id=21639 - https://bugs.winehq.org/show_bug.cgi?id=22798 Upgrading AppDB may also enable it to evolve in a more modern flexible direction toward protondb which may encourage more user engagement and assist maintainers with more convenient workflows: - https://www.protondb.com/app/1042380 There is much more to discuss but please consider this hardly urgent enough to distract from much higher priorities. If anyone has any suggests, requests, or feedback regarding their experience with AppDB and how it may be improved outside what has already been reported for Bugzilla or what may be currently be considered outside the realm of possibility then please feel free to report it here. In the meantime I continue to work in my spare time toward a proof of concept for review based on my exposure to AppDB and experience with CMSs. -- 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.

1 10