REQUEST: refactor of w_workaround_bug using info from bugzilla

[Kreyren]

We can use curl https://bugs.winehq.org/show_bug.cgi?id=47565 2>/dev/null | grep "static_bug_status" to get status of winebug directly from bugzilla:

kreyren@dreamon:~$ curl https://bugs.winehq.org/show_bug.cgi?id=47565 2>/dev/null | grep "static_bug_status"
      <span id="static_bug_status">UNCONFIRMED

I believe that this opens new posibilities in making winetricks self-sufficient in terms of applying workarounds depending on bug status and wine used assuming that reporters fills metadata of the bug correctly alike:

kreyren@dreamon:~$ curl https://bugs.winehq.org/show_bug.cgi?id=47565 2>/dev/null | grep "page.cgi?id=fields.html#version" -A 5
      href="page.cgi?id=fields.html#version"
  >Version:</a>
</label>
</th>
        <td>4.12.1
  </td>

To get the affected wine version, etc..

---

To make winetricks work offline we could probably stash these definitions in cache.

[austin987]

It's a neat idea, but it would be tricky in practice: A) the reported version doesn't mean much. That's only when it was reported, it could've been there before. In addition, users often like to change it, and triagers don't always catch it and set it back. B) There's no field describing the fixed version. You could theoretically parse AJ's closing comment, but that's not automated and could change (and also doesn't guarantee that's when the bug was fixed, just when it was reported and marked fixed. C) You'd want to make this optional, users with slow/no connection don't want to waste bandwidth/time, and it has privacy issues as well.

[Kreyren]

A) the reported version doesn't mean much.

We could change Bugzilla's Metadata to allow inputting range of affected versions in that case assuming it being Bugzilla it should be easy to implement. (basically changing the default form?)

That's only when it was reported, it could've been there before. In addition, users often like to change it, and triagers don't always catch it and set it back.

Well if users change it on the bug we will be the first to notice it and fix it.. in then I believe it's just a matter of educating the community to know how to file the Metadata (and winedevs since lots of bugs has wrong metadata)

B) There's no field describing the fixed version. You could theoretically parse AJ's closing comment, but that's not automated and could change (and also doesn't guarantee that's when the bug was fixed, just when it was reported and marked fixed.

yes change in Bugzilla's Metadata would be required to allow specifying the exact affected versions from there we could make logic in winetricks.

C) You'd want to make this optional, users with slow/no connection don't want to waste bandwidth/time, and it has privacy issues as well.

Any idea how could we implement this? I guess providing default definitions for bugs with winetricks releases and from there allow using function in winetricks to update them from bugzilla?

Other then that it's probably packaging issue for downstream

for privacy winetricks has torify etc.. so in terms of privacy that should be an issue.

---

For bugzilla i remember working on a project that had bugzilla setup in a way that only outputed formated metadata for specialized url extension. I think that it's already a part of bugzilla which would allow us to implement the function easier, but investigation is needed.

[austin987]

While I could change bugzilla, I'm not going to do it willy nilly. In particular, this would require editing all fixed bugs to be useful, which is extremely impractical.

In addition if you think educating the community to follow standards is trivial, you aren't following closely. I've worked on wine bugzilla for over a decade.. It's not.

While I'm tempted to close this, I do think it's a neat idea. But requiring chess upstream impractical and will need a much, MUCH stronger argument.

That said, this isn't your blog, please keep comments to a minimum.

[Kreyren]

this would require editing all fixed bugs to be useful, which is extremely impractical.

I believe that it would require only editing new bugs and those that are affecting winetricks to be used for logic and we can just check all bugs that are currently workarounded in winetricks (basically every mension of w_workaround_bug..) and edit it's metadata which i'm willing do to.

In addition if you think educating the community to follow standards is trivial, you aren't following closely. I've worked on wine bugzilla for over a decade.. It's not.

From my point of view current instuctions on bugzilla aren't exactly strait forward for non-winehq members.

If it was me i would just make the Version mandatory to be filled prior to submiting a bug so that bugzilla woudn't allow making a bugs that doesn't have wine version specified. Same could probably be applied for other metadata.

will need a much, MUCH stronger argument.

Is proposed in this comment sufficient? if not provide reasoning and i believe that we can find a sufficient solution.

---

That said, this isn't your blog, please keep comments to a minimum.

Elaborate?

[Kreyren]

headsup: Winebug submitted https://bugs.winehq.org/show_bug.cgi?id=48169

EDIT: Submitted with full proposal after a research

[tannisroot]

Elaborate?

i'm not Austin but you spam in this repo with various notes like it's your blog :/

[Kreyren]

i'm not Austin but you spam in this repo with various notes like it's your blog :/

Noted, aldo i don't know what else is expected from me to provide the expected contribution.

[tannisroot]

If you want to contribute, making new verbs would be nice :+1:

[mirh]

This doesn't really make sense. Like half of the bugs are closed and reported "fixed" tons of versions (if not years) after the actual fix. If you can get Julliard to change his reporting model after 20 years, good enough, otherwise even bugzilla parsing data by itself is useless.

[paulwratt]

Fixed by SHA1: | 7ca1c4900e42d608150822ef87a7ce2847a59b6f

maybe due to the submitted Winebug but at least that commit tag allows verification, not sure how to tie that to a wine release version tho, without further research.

(edit: I did see a "commit" url in the initial output of the next post 1st XML url, that may help)

My opinion on expressive development posts: as long as they are on topic, those that complain about them are usually terrible at providing documentation for others (in some form or another). I might remind people that a (GitHub Issues != git commit). People spending all day on GH Issues may think otherwise.

[paulwratt]

the workaround in the "headsup" (linked) post that provides XML output is untenable for the OP url (its been (was 5 now) 10 minutes and its still not done - I just stopped it after 15min and its still going - it broke after 22 min - and cos it broke you cant view any output in chrome) https://bugs.winehq.org/show_bug.cgi?ctype=xml&id=47565

A compromise for Bugzilla would be: to be able to retrieve a header only without any comments. ie without the <long_desc .. tag content. https://bugs.winehq.org/show_bug.cgi?ctype=xml&id=48169

a "short=true" would allow both HTML & XML "header view" without intefering with existing functionality.

To be concerned with the users privacy, "winetricks --self-update" would have to be dropped as that connection is now "owned by Microsoft" who are well publicised for their products security and not at all known for collecting excessive amounts of telemetary (sic).

I would suggest any winetricks url grabs be assisted by a "winetricks" browser string, at least those (working) on bugs.winehq.com would be able to get useful information from it. I dont believe GitHub has Browser connection statistics per project, but I may be wrong, and if they do publish public stats "winetricks" would be present for "updates". Archive.Org would also find it invaluable, especially if they were to impliment a "wintricks" speciality server/space (see #1696 & #1677)

both of these (header only & browser string) seem useful to the greater wine project, and could be extended to the other helper projects (winetricks, kreytricks, phoenicis, lutris, etc..)

a "header only" would be useful for adding data analysis to wine project management, considering the amount of regessions between versions - ie all open bugs that have winetricks workarounds - all "closed" but not "fixed" (eg #1476) - and could be used to directly referenced against commit logs/history (where commits are present in the header, as mentioned in above post)

actually if that 1st example was run before a winetricks version release you could verify the need for workarounds on the spot, and make adjustments to that release. That too could be combined with at external (in project tree) list of required workarounds for a specific wine version (knowing there are "good" and "bad" versions of wine), without the need to maintain them in the current winetricks version.

[paulwratt]

you can get a "fake" header at a console shell prompt with the following:

U="https://bugs.winehq.org/show_bug.cgi?ctype=xml&id=48169" ; N=$(curl -s "$U" 2>/dev/null | grep -nm 1 long_desc | cut -d \: -f 1); curl -s "$U" 2>/dev/null | head -n $(($N-1)) | sed '/^[[:space:]]*$/d'

yes there are 2 url pulls, but thats because "long_desc" 1st line number changes depending on "bug" content (may have "Duplicates:" & not "Fixed by SHA1:"), and the last sed command removes blank lines (incl. space padded) - thankfully it appears that all previous tags (barring the Bugzilla tag) are single line value pairs.

note: there are values pairs present in the XML that are not present in the HTML (eg "resolution", "everconfirmed", etc)

[paulwratt]

Ok so where there is a "Fixed" commit entry, the URL field is also filled to the git commit, and the that page contains a date that might be used to cross reference a wine version

(referenced: https://bugs.winehq.org/show_bug.cgi?id=47565)

[paulwratt]

if the WineHQ Bugzilla is kept up to date with the main Bugzilla project, it would make sense to get it added there.

I also believe JSON output would be more useful (via 'jq')

---

there is a way to get the version based on both "Regression SHA1:" and "Fixed SHA1:" (in XML the url is passed through bug_file_loc), by pulling VERSION from a "Fixed SHA1:" (modified) url that points to the tree of said commit: https://source.winehq.org/git/wine.git/tree/7ca1c4900e42d608150822ef87a7ce2847a59b6f https://source.winehq.org/git/wine.git/blob/7ca1c4900e42d608150822ef87a7ce2847a59b6f:/VERSION https://source.winehq.org/git/wine.git/blob_plain/7ca1c4900e42d608150822ef87a7ce2847a59b6f:/VERSION reference: https://bugs.winehq.org/show_bug.cgi?id=47565