[Bug 48169] New: Downstream: Adapt metadata to be fetched in logic
https://bugs.winehq.org/show_bug.cgi?id=48169 Bug ID: 48169 Summary: Downstream: Adapt metadata to be fetched in logic Product: WineHQ Bugzilla Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: werifGX(a)gmail.com CC: austinenglish(a)gmail.com Distribution: --- Referencing https://github.com/Winetricks/winetricks/issues/1392#issuecomment-545308510 # Proposal I want to propose adapting bugzilla's metadata to be used in POSIX sh (winetricks) in such a way that could query the status of the bug, check end-user's system and depending on used metadata apply a workaround for end-user's system untill said bug is resolved. # Reasoning Currently winetricks is using simple function (w_workaround_winebug) to check if end-user's system is affected by any winebug which is not very reliable since it's checking for only for specified wine version which eventually result in lots of winetricks bugs that are applying unnecesary workarounds for example dotnet20 removing $W_SYSTEM32_DLLS/msvc?80.dll on wine-4.20 due to the winebug 10467 that affects wine <0.9.49 (https://github.com/Winetricks/winetricks/blob/f194322885b7d674c7b22a8283cbf0...) and current winetricks is full of issue alike. I believe that contributing this in winetricks to adapt logic per used workaround is not an ideall solution since there are bugs about which we don't know which wine versions they affect (for example https://bugs.winehq.org/show_bug.cgi?id=47820) and tracking all bugs is heavy on maintenance. # Proposed solution ## Better management of bug status Currently bugzilla is using unreliable way to track bugs that is difficult to be implemented in this scenario for this to work we would need better status management to be implemented such as: - if bug status STAGED is used on end-user's system that is not wine-staging -> Output error/die. - if bug status is CONFIRMED, skip applying workaround etc.. ## More options in 'Version:' metadata We can also use wine version which would require more options in "Version:" metadata that allows us to adapt affected versions in said scenario example winebug specifies that affected wine versions are 4.13, 4.15 and 4.18~4.20 -> If end-user is using affected version attempt to apply a workaround or output an error ## Injecting logic in winetricks In theory there could also be a section in metadata that allows us to check end-user's wine for problematic codeblock for example winebug https://bugs.winehq.org/show_bug.cgi?id=22053#c65 which was affected by bug in gcc where on some system we can use `strings -a wine |grep "GCC"` or `readelf --debug-dump=info wineserver | grep DW_AT_producer` to check which gcc was used to build said wine that can be implemented in the logic and can be placed on the bug itself. # Possible problems - End-users with slow internet connection would have to rely on hard-codded logic unless bugzilla would allow us to fetch a raw file with metadata on the bug (instead of using 'curl' piping to grep and posix regexing whole page) - End-user without an internet would have to still rely on hard-coded logic unless there is some automation done that updates the code automatically based on bug status. --- I'm wiling to work on implementation assuming changes made in bugzilla since i would also like to use this in my fork (https://github.com/Kreytricks/kreytricks) -- 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=48169 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- Most of this sounds unmanageable. Testing, and winetricks, should focus on current codebase first; bugzilla is used to track issues not to track a set per-application set of wine version ranges, that's supposedly work. Purpose of version field is to see how old issue is approximately, as a hint. -- 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=48169 --- Comment #2 from Jacob Hrbek <werifGX(a)gmail.com> --- (In reply to Nikolay Sivov from comment #1)
Most of this sounds unmanageable.
Can you elaborate? Note that if this proposal does not expect any additional maintenance from winehq since this is expected to be an optional metadata to be used for downstream like winetricks,kreytricks,phoenicis,lutris, etc..
bugzilla is used to track issues not to track a set per-application set of wine version ranges, that's supposedly work. Purpose of version field is to see how old issue is approximately, as a hint.
Why as a hint assuming that there is a date when the bug was submitted and bug number (lower bug number -> Older the issue) -- 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=48169 --- Comment #3 from Jacob Hrbek <werifGX(a)gmail.com> --- (In reply to Jacob Hrbek from comment #0)
- End-users with slow internet connection would have to rely on hard-codded logic unless bugzilla would allow us to fetch a raw file with metadata on the bug (instead of using 'curl' piping to grep and posix regexing whole page)
This is resolved since bugzilla already supports this: https://bugs.winehq.org/show_bug.cgi?ctype=xml&id=48169 -- 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.
participants (1)
-
WineHQ Bugzilla