User talk:Konstin

Software version

About User:Github-wiki-bot please always mark as preferred rank the latest software version added. --Valerio Bozzolan (talk) 21:13, 25 January 2017 (UTC)[reply]

Due to the limitations of the pywikibot, which the bot is built upon, the rank is can only be added on the second pass over an entry. As long as I don't have a fix for that problem in pywikibot, there will be a unavoidable lag between adding the versions and setting the preferred rank for the latest version. Any help on this problem is welcome! Konstin (talk) 21:48, 25 January 2017 (UTC)[reply]

How much lag? hours? --Valerio Bozzolan (talk) 20:44, 26 January 2017 (UTC)[reply]

If I always do two consecutive runs (which I didn't in the past because missing ranks didn't seem much of an issue) the lag should be less than half an hour. Konstin (talk) 20:47, 26 January 2017 (UTC)[reply]

So I think that it is not a problem :) Just please remember to do it, because in the contrary our it.wiki templates will explode :^) Thanks. --Valerio Bozzolan (talk) 11:07, 28 January 2017 (UTC)[reply]

I've changed the behavior to always run twice, so this problem should be solved. --Konstin (talk) 16:48, 30 January 2017 (UTC)[reply]

It seems not at all d:Q647055 (see what it means for our templates: it:CakePHP) --Valerio Bozzolan (talk) 14:53, 2 February 2017 (UTC)[reply]

I finally found time to fix that. The problem was that it didn't set the rank when there are more than 100 releases. I've tested this on CakePHP and it worked, so hopefully it now works for all projects. Thanks for reporting that! --Konstin (talk) 16:59, 17 February 2017 (UTC)[reply]

Hi - I noticed that this edit resulted in two preferred ranks. Please make sure that when updating the latest stable release (and only that stable release) has a rank of "preferred". If multiple versions are listed as "Preferred", pages on Wikipedia pulling in the data, such as Discourse and Comparison of Internet forum software will pull in ALL versions of this rank, which is a mess. Greenman (talk) 21:35, 6 March 2023 (UTC)[reply]

Please stop. This bot is continuing to break pages by messing up the preferred rank. Greenman (talk) 08:04, 30 November 2023 (UTC)[reply]

What pages and claims specifically are you referring to? Konstin (talk) 08:55, 30 November 2023 (UTC)[reply]

Recent example of having no preferred rank (in fact I fixed this after an earlier bot run, and then the bot reverted it). This mangled the resulting display on both the Play Framework and Comparison of server-side web frameworks page. There are actually 2 separate kinds of behaviour that result in problems. One is if the bot adds a second preferred rank. This can be worked around, but should be done at the same time as the update (see for example this fix). The other is if there are no preferred ranks, which is what the earlier discussion, and the recent example, refers to. I suggest keeping an eye on the Comparison of server-side web frameworks page - as more entries make use of wikidata, problems appear more readily on large pages like this and List of content management systems. Greenman (talk) 07:11, 5 December 2023 (UTC)[reply]

There have been two more removals of the preferred ranking by the bot since the above (one two). Greenman (talk) 19:38, 11 December 2023 (UTC)[reply]

This is strange - The bot first sets all other versions to normal, then updates the latest version to the preferred rank (https://github.com/konstin/github-wikidata-bot/blob/d582ef0ebfaae96b6fe57dda341e4ebfc61070c3/github_wikidata_bot/main.py#L247-L296); I unfortunately wouldn't know how to do both a the same time atomically with pywikibot. One thing that might have happened is that sometimes the wikidata API returns an edit conflict when changing the rank (i haven't understood when yet), which could leave two preferred ranks. I now changed this so that failure in the preferred rank -> normal rank change means we don't set a preferred rank for the new latest version claim later (https://github.com/konstin/github-wikidata-bot/blob/d582ef0ebfaae96b6fe57dda341e4ebfc61070c3/github_wikidata_bot/main.py#L247-L296). I've also increased the log size so we can check whether the edit conflict has something to do with this. Konstin (talk) 00:59, 13 December 2023 (UTC)[reply]

Thanks, I'll keep an eye on the page. Although note that the recent problems were caused by having no preferred rank, after the bot unset the single preferred rank entry. There were 2 more (one, two), but these were both prior to your notice here, so let's see if it helps. Greenman (talk) 06:56, 13 December 2023 (UTC)[reply]

Nope, another breakage. I see there's an exceptions page, I've added the item there for now. Greenman (talk) 07:59, 14 December 2023 (UTC)[reply]

Resetting an old version to preferred rank happened here and then twice more for the same version and item. It is not clear why, but there are a lot of version statements for this software. The result was an error in the w:Zotero infobox because two dates were returned, which is not recognized by w:Template:start date and age. GreenReaper (talk) 21:57, 20 March 2024 (UTC)[reply]

This should hopefully be covered by the same fix as User talk:Konstin#c-Bender235-20240317202800-Bot version update malfunction. I tried an unknown version with preferred rank manually and the bot now seems to respect it. Konstin (talk) 15:45, 23 March 2024 (UTC)[reply]

Release date

Github-wiki-bot is adding two release dates though it should only add one. See this diff. The issue is that it considers the release candidate as a regular release of the same version. Thanks --[[kgh]] (talk) 06:17, 9 April 2017 (UTC)[reply]

The problem is that the release candidate on github ([1]) isn't labeled as a prerelease, but as a normal release. The most simple solution would be to mark all rc's on github as prerelease and then remove the wrong the dates. Konstin (talk) 10:46, 9 April 2017 (UTC)[reply]

Thanks for the info. In this case this was an easy solution since I can control the repo mentioned. However I can imagine there there are heaps of other repos with uncontrolled behaviour. So having at least semver compliant flag checks will be a great enhancement I guess. --[[kgh]] (talk) 11:11, 9 April 2017 (UTC)[reply]

What do you mean with "semver compliant flag checks"? The current behavior is to try to guess the version number from the string given, which works quite good for all I can tell.

Well semver requires to add flags to the version to identify the status, e.g. -alpha.1 for alpha releases, -beta.1 for beta releases, -rc.1 for release candidates, etc. as flags suffixed to the version. So an easy logic is probably: As soon as there is a flag it is not a stable release. More complex logic would try to translate the flag into a status. The latter is not necessarily needed for Wikidata I believe. --[[kgh]] (talk) 11:20, 9 April 2017 (UTC)[reply]

Checking for semver suffixes was a good idea, but unfortunately people develop an impressing creativity when it comes to version numbers. I did a lot of experimenting until I eventually had the following regex which catches all the cases I could find: "[ -._\d](r|rc|beta|alpha)([ .\d].*)?$". I've deployed the new version to the server, which means that no more bogus release dates should be added. I'm not going delete any of the existing dates myself, because there are too many to check them all for false positives myself. See this query for a list of cases. If you (or anyone else) finds cases which are missed by this regex, just tell me and I'll try to include them. Thanks for reporting this anyway! --Konstin (talk) 20:31, 12 April 2017 (UTC)[reply]

I have to thank you for tackling this issue! Just cleared three objects and we will see what happens. :) These dupes will clear out eventually by community edits. --[[kgh]] (talk) 21:46, 12 April 2017 (UTC)[reply]

Something is going wrong: see this diff. Is there something I can do to prevent this? Cheers --[[kgh]] (talk) 22:15, 10 April 2017 (UTC)[reply]

Yes, I know this is wrong, and fixing this is already on my todo list. But coding and testing is a time consuming task, so I can't fix this immediately. Konstin (talk) 22:22, 10 April 2017 (UTC)[reply]

Ah, ok, I thought that I probably had to do something here. Well, if it is an known issue on your list everything is ok I believe. No worries since no current version is affected. I am on close watch. Keep up you work! Cheers --[[kgh]] (talk) 22:29, 10 April 2017 (UTC)[reply]

This is just to note that the bot still continues to add multiple release dates to the same release. --[[kgh]] (talk) 21:48, 13 April 2017 (UTC)[reply]

I think that diffs like https://www.wikidata.org/w/index.php?title=Q4914654&diff=713032408&oldid=713032403 are doing some kind of date defaulting that seems wrong, causing a problem for the "oldest software" demo

Official website

Hello! Thanks for you contributions! Please pay attention that we are reverting some changes made by the User:Github-wiki-bot that insists in saving a duplicated official website (e.g. scikit-learn (Q1026367)). For now I propose: stop adding an official website if it is yet present (even totally different). For the future, the bot should consider a trailing slash as not important, so http://asd.com and http://asd.com/ should be considered duplicates :) --Valerio Bozzolan (talk) 12:55, 6 May 2017 (UTC)[reply]

Please, note this message. --Valerio Bozzolan (talk) 22:56, 7 May 2017 (UTC)[reply]

I've changed the bot so that it doesn't add a new website link if one does already exist. Unfortunately it's not feasible to check whether two urls are semantically equal (e.g. the only difference is a trailing slash) as some servers are very picky about those details. --Konstin (talk) 06:58, 8 May 2017 (UTC)[reply]

Thank you for this patch :) --Valerio Bozzolan (talk) 07:31, 8 May 2017 (UTC)[reply]

CakePHP 100 releases

Thank you for your great Github-wiki-bot. CakePHP releases https://www.wikidata.org/wiki/Q647055 no longer gets inserted, it may be related to the limit of 100. Can you have a look into this issues? ---- (talk) 13:39, 6 September 2017 (UTC)[reply]

Another example: Symfony https://www.wikidata.org/wiki/Q1322933 ---- (talk) 15:14, 6 September 2017 (UTC)[reply]

Given that you've got basic python skill you can fix it yourself (main.py), but I currently don't have time for that --Konstin (talk) 09:47, 8 September 2017 (UTC)[reply]

Preferred rank source code repository

If there is more than one source code repository but only one of them has "Preferred rank" that one should be used. Example: SonarQube ---- (talk) 08:26, 8 September 2017 (UTC)[reply]

It afaik currently only uses the one with the preferred rank.

Opt-in to XTools for User:Wikidata-github-bot

Hi, if you don't mind could you opt-in to XTools, to allow the tool to show more information about the bots activity? This would allow use to easily see how many edits the bot does per month, etc. To do so log in as User:Wikidata-github-bot and create the site User:Github-wiki-bot/EditCounterOptIn.js with any arbitrary content. Thanks! -- MichaelSchoenitzer (talk) 20:53, 19 November 2017 (UTC)[reply]

Thanks for the hint, I've opted in! -- Konstin (talk) 21:12, 19 November 2017 (UTC)[reply]

Thank you! -- MichaelSchoenitzer (talk) 14:15, 20 November 2017 (UTC)[reply]

Github-wiki-bot

Hi, I'm creating a few issues on github, for things that I found about this bot. I also plan on working on them eventually. But if someone else wants, even better. ;) -- MichaelSchoenitzer (talk) 16:37, 2 December 2017 (UTC)[reply]

Rank

When adding a new relase to a subject, e.g. Matomo it correcty sets the rank of the former release from preferred to normal however it fails to set the rank to preferred for the new release. As a result an arbitrary version is shown in the info boxes at Wikipedia. A fix will be great. --[[kgh]] (talk) 23:15, 12 January 2018 (UTC)[reply]

The bot is setting the preferred rank, though this sometimes doesn't work on the first pass due to a bug in the library I'm using. This is normally resolved a few minutes later by the second pass. You were most likely just quicker with your edit than the time between the first and the second pass of the bot. --Konstin (talk) 14:39, 13 January 2018 (UTC)[reply]

Ok, faster than the bots. :) Thanks for the info! Cheers --[[kgh]] (talk) 18:57, 13 January 2018 (UTC)[reply]

I finally found the time to fix this more properly. The difference between inserting a version and setting the correct rank should now only be a fraction of a second. --Konstin (talk) 18:38, 11 March 2018 (UTC)[reply]

Speaking of the rank, this bot seems to mess with the software versions in Q191782. There are several new stable versions, but no matter who tries to fix the preferred rank, the bot sticks to 2.1.3 and reverts any edits on this particular version for unknown reason. Maybe you should take a look at it. I'd also suggest this bot should state his reason in the summary. --CodeOne (talk) 10:22, 30 March 2018 (UTC)[reply]

The bot assumed that the latest release on github (https://github.com/audacity/audacity/releases) would be reliable. On github, audacity only has releases for version until 2.1.3, the newer versions are just git tags, so the assumption fails. I've changed the bot so that it doesn't set the preferred rank if there already is a preferred rank on a version the bot doesn't know about. In the case of Q191782 this means that the bot first assumes that 2.1.3 should be given the preferred rank. It than sees the preferred rank on 2.2.2, realises that there isn't a github releases for that and decides to give 2.1.3 a normal rank. I hope this is an adequate solution. --Konstin (talk) 13:45, 30 March 2018 (UTC)[reply]

I see, that was the reason. Thanks! This solution indeed might work. --CodeOne (talk) 20:05, 30 March 2018 (UTC)[reply]

Please disable the github bot

It is doing more harm than good. It is adding wrong values, moreover to statements already made, e.g. Q20728. Thanks --[[kgh]] (talk) 07:56, 16 March 2018 (UTC)[reply]

Could you please specify what wrong values the bot is adding? --Konstin (talk) 11:01, 16 March 2018 (UTC)[reply]

It is e.g. adding duplicate as well as wrong values for P548. --[[kgh]] (talk) 11:08, 16 March 2018 (UTC)[reply]

Oh, I'm just realizing that P548 is not "stable version" as the label suggests, but actually supported version. I've removed the P548-adding Part from the bot. (For reference: PR #17 and b6abd1) --Konstin (talk)

I dug through the values of P548 and it's usages and I'm now pretty sure it is not meant to indicate whether a version has support, but to differentiate between alpha, beta or stable releases. This is also how it's used in most manually edited projects I've seen. Furthermore there is P2669 "discontinued date" to indicate end of life (which is much more useful as it tells when the version became will become unsupported). I've opened a request to change the description of stable version and obsolete version accordingly: https://www.wikidata.org/wiki/Property_talk:P548#Usage_of_P548_for_to_indicate_the_support_of_a_release --Konstin (talk) 13:00, 17 March 2018 (UTC)[reply]

Thanks for swiftly fixing your bot! My wish for the future is that it should check if a value for a statement was already added instead of just adding another duplicate and contractictory statement. Perhaps this check was already implemented, I do not know. However in the past I had to fix the bot's edits many many times and I feel stupid about this since I cannot compete with machines. Thus I have lost a lot of valuabel time. --[[kgh]] (talk) 16:01, 17 March 2018 (UTC)[reply]

Agreed, the bot shouldn't override existing values or add false ones when correct ones are existing. I've changed this for publication date which now checks that there isn't one already set. Overriding the preferred rank is intended, while other changes shouldn't cause problems with existing values. For the future I'd suggest reporting bogus changes by the bot here or in the github repo. It's normally much easier to change a few lines of code for a futureproof fix than to manually revert every single change. --Konstin (talk) 23:43, 17 March 2018 (UTC)[reply]

@Kghbln: Actually this error was on me! I built in the support for P548 and didn't check if we already check if the qualifiers are there already but just assumed. I'm sorry – I will make sure to double check next time. -- MichaelSchoenitzer (talk) 12:54, 18 March 2018 (UTC)[reply]

Mistakes can happen and since this one was resolved... Thanks to both of you for working on fixing the bot. Still something is wrong. I continues to add additional contradictory release dates. An issue I reported on this very page in April 2017 already. It will be great to finally have a fix for this one, too. I have seen this on many pages which I did not fix. Thanks --[[kgh]] (talk) 07:54, 20 March 2018 (UTC)[reply]

Take for example Q34162 where we have up to 9 release dates per version. Thus checks for existing values were feasible will be great to have. --[[kgh]] (talk) 07:35, 28 March 2018 (UTC)[reply]

As I've said I've added a check against this happening again. I just checked with Matomo specifically and the check is working. Dealing with existing duplicates is more difficult; I'm not aware of any sound way of picking a correct value without overriding values added by humans. --Konstin (talk) 01:26, 29 March 2018 (UTC)[reply]

Cool, thanks for confirming. Issues like at Matomo need to be cleared by humans I guess. No worries. Cheers --[[kgh]] (talk) 20:29, 31 March 2018 (UTC)[reply]

Since there was no negative feedback on the discussion, I've removed the "is supported" part from the stable version and obsolete version. --Konstin (talk) 12:16, 16 May 2018 (UTC)[reply]

This bot remove privileged rank on stable version of software

The User:Github-wiki-bot, on LMMS (https://www.wikidata.org/wiki/Q201809), it removed privileged rank, on stable version, not on RC version, this made 'advandced/beta version' appear correctly on wikipedias, but all the stable appear in their infoboxes. Could this function be removed ? 23:45, 31 August 2018 (UTC)[reply]

@Popolon: Hi, I changed the bot so that when there is a unstable-version with high rank the ranks of all versions will not be changed. There is however a deeper problem: Currently there is no consensus of how the ranks should be set for (unstable) versions. Most items have the preferred rank only for the current stable version and all other versions – including the current unstable version – with normal rank. The way how Wikipedias handle the versions is also different. Which Wikipedia where you referring to? Also if you want github-wiki-bot to skip some item due to problems with this you can add it to this page. -- MichaelSchoenitzer (talk) 12:01, 1 September 2018 (UTC)[reply]

That was the case in fr.wikipedia (and it's again a problem) (you removed high rank on stable version !!!). I see that en.wikipedia is not impacted. I believe this is not easy to parse between different 'advanced' versions (beta, RC, git, etc...). Thanks for the answer, I will look soon at this page and add comments.Popolon (talk)

enwiki currently does not use Wikidata at all. dewiki only for the stable versions. Sorry for my change, I was running the bot to test where the bug was and forgot to undo the change. -- MichaelSchoenitzer (talk) 12:25, 1 September 2018 (UTC)[reply]

Edit introduced single value constraint violation

https://www.wikidata.org/w/index.php?title=Q334879&type=revision&diff=866573769&oldid=866560335

Added a second value to the official website (P856) property. This violates the single value constraint for P856. Trilemma2 (talk) 21:36, 25 February 2019 (UTC)[reply]

Fixed in https://github.com/konstin/github-wikidata-bot/commit/3eaeed204d32900a169a28ea343c14285531fd3f, but not yet deployed. Konstin (talk) 00:10, 27 February 2019 (UTC)[reply]

I've deployed the fix. Konstin (talk) 22:36, 4 March 2019 (UTC)[reply]

ERROR There are duplicate releases

Thank you for creating Github-wiki-bot! We have a litte ERROR with Q22442795 because the bot finds duplicate releases. In https://github.com/scikit-image/scikit-image we find on 2015-03-05 a release "0.11.2" and a second release on the next day: "v0.11.2". This is documented in the logfile of Github-wiki-bot: "ERROR There are duplicate releases in Q22442795: [Release(version='0.11.2' ...." This error prevents the bot from updating wikidata with new versions. Do you have a solution for this? MTheiler (talk) 11:57, 4 March 2019 (UTC)[reply]

I fear there's no good automated solution for this problem. You could of course add the tags manually or you could ask the maintainers to delete the two bogus tags, but I don't know of any good way how the bot itself could resolve such conflicts. Konstin (talk) 12:42, 4 March 2019 (UTC)[reply]

Git Wire Protocol

Please see the discussion at Talk:Q186055#Git Protocol. Daask (talk) 22:58, 17 March 2019 (UTC)[reply]

I'm open to changing the protocol, however you should gather consensus first on what the preferred usage of protocol (P2700) is. Konstin (talk) 23:50, 17 March 2019 (UTC)[reply]

Nginx beta versions and Github-wiki-bot

There is a problem with Github-wiki-bot and nginx versions. it write as stable all the 1.15.x that are beta version. all even version (1.16, 1.14...) are stable and all odd (1.15, 1.13...) versions are beta (mainline in nginx terminology : http://nginx.org/en/download.html)

From what I can tell by nginx's blog, I disagree that mainline corresponds to beta. I'd rather say that mainline is a normal release, while stable release are LTS releases. E.g. https://www.nginx.com/blog/nginx-1-12-1-13-released/ says "We generally recommend using the mainline branch." Konstin (talk) 14:49, 26 April 2019 (UTC)[reply]

The bug occured again, 1.17 (beta) was added without type of version, and 1.16 stable) priority was removed. So on fr wiki 1.17 was displayed as stable and all beta version was displayed ad last beta. Popolon (talk) 08:02, 14 June 2019 (UTC)[reply]

I still disagree that 1.17 is a beta release. E.g. http://nginx.org/en/download.html shows 1.17 as top entry as "mainline release". --Konstin (talk) 13:38, 23 June 2019 (UTC)[reply]

Broken again, the releases version https://www.wikidata.org/w/index.php?title=Q306144&diff=962648442&oldid=962068757 Popolon (talk) 13:31, 21 June 2019 (UTC)[reply]

Problem still persist.Popolon (talk) 10:21, 16 February 2024 (UTC)[reply]

I've tried a different strategy for changing the rank, maybe that helps Konstin (talk) 18:47, 2 March 2024 (UTC)[reply]

Hi Konstin! Thanks for the useful bot. Cheers! -- Meisam (talk) 13:07, 22 June 2019 (UTC)[reply]

Github-wiki-bot should not touch deprecated version ranks

See for example: https://www.wikidata.org/wiki/Q6542725. There are version items 1 2 3 4, which are outdated and precede normal versioning schema. The bot marks 4 as the latest version which is incorrect: https://www.wikidata.org/w/index.php?title=Q6542725&type=revision&diff=991216806&oldid=991216805. This (and other cases with changed versioning schema, where new versions compare less than older versions) can be/is solved by setting deprecated rank to the old versions. The bot thus should leave deprecated ranks untouched (while it could still update statuses, references and other information). --AMDmi3 (talk) 15:00, 26 August 2019 (UTC)[reply]

I've created an issue to track that: https://github.com/konstin/github-wikidata-bot/issues/96 --Konstin (talk) 12:15, 17 September 2019 (UTC)[reply]

The bug has been fixed (The bot won't touch versions with a deprecated rank anymore) and I've manually verified that this works for LibrePlan as intended. --Konstin (talk) 20:48, 17 September 2019 (UTC)[reply]

source code repository

Your bot did wrong edits on source code repository (P1324) in many Wikidata items in the past hours. The urls are not valid. Behanzane (talk) 23:57, 20 October 2019 (UTC)[reply]

Very much indeed. Moreover it edited pages where we already have valid information on this and replaced it, e.g. on Q47528699. A fix of the bot will be great. Cheers --[[kgh]] (talk) 07:03, 21 October 2019 (UTC)[reply]

Sorry for the mess, I've fixed the bot and all broken urls. -- Konstin (talk) 14:05, 21 October 2019 (UTC)[reply]

No worries. Thanks for attending to it and all your work. --[[kgh]] (talk) 15:42, 21 October 2019 (UTC)[reply]

Bot malfuntioning

In this diff, your bot seemed to mess up the Github URI. --SixTwoEight (talk) 10:47, 21 October 2019 (UTC)[reply]

here is another mess. — Finn Årup Nielsen (fnielsen) (talk) 12:05, 21 October 2019 (UTC)[reply]

Sorry for the mess, I've fixed the bot and all broken urls. --Konstin (talk) 13:59, 21 October 2019 (UTC)[reply]

EditGroups support

Hi! Thanks for adding EditGroups support to your bot. However, it looks like there is a bug:

https://www.wikidata.org/w/index.php?title=Q30645415&diff=prev&oldid=1044472910

In this edit (and others) the release title and the edit group id seem to have been swapped. − Pintoch (talk) 07:27, 4 November 2019 (UTC)[reply]

Oops, thanks for notifying me. Hopefully that's fixed now. --Konstin (talk) 17:13, 4 November 2019 (UTC)[reply]

Github urls

Isn't the "correct" url for a git repo on github of the form

https://github.com/ray-project/ray.git

Not

https://github.com/ray-project/ray

? The bot prefers the latter though it seems while the former is more accurate? BrokenSegue (talk) 16:05, 4 February 2021 (UTC)[reply]

According to https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/cloning-a-repository it's `https://github.com/YOUR-USERNAME/YOUR-REPOSITORY`, while the UI suggests `https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git`, and I haven't found any more authoritative sources, so it appears to me that either is fine. --Konstin (talk) 20:07, 4 February 2021 (UTC)[reply]

Github-wiki-bot / date tagged vs date published

Hi, the bot assumes that the date published on GitHub is identical to the date tagged. Though this would indeed be nice it is in reality not true in all cases, sometimes these dates may diverge by many YEARS. Thus I suggest that this bot checks if a publishing date was already added here in Wikidata and as a consequence does not add another publishing date. I have seen many cases with duplicate and diverging publishing dates which are all but correct. Thanks and cheers --[[kgh]] (talk) 16:10, 13 April 2021 (UTC)[reply]

The bot should already prefer an existing date over the github tag (source). Do you have an example of a case where this doesn't happen? --Konstin (talk) 15:15, 19 April 2021 (UTC)[reply]

Hmm, it seems that the bot is indeed now working as expected. What triggered my post was this diff which made me realize a lot of duplicate release information which I removed (together with other false information). Obviously I did not check closely. I figured that they there added with this lot. Now, looking closer it appears that only references were added with is very fine. The dupes must have been added with an earlier version of the bot. I guess we are cool. :) Thanks a lot for your great work here! Please excuse the noise. Cheers --[[kgh]] (talk) 18:02, 19 April 2021 (UTC)[reply]

Roslyn's confusing release notes

Hi, related to User:Github-wiki-bot: if you have time, please check Q6840207 / Roslyn which has unusual release numbering and release notes and the bot seems to be confused processing it. It's great for debugging for sure. :) ~ Boro (talk) 11:36, 9 May 2021 (UTC)[reply]

I'm afraid the bot won't be able to reason with that, I've added the page to the block list --Konstin (talk) 14:16, 17 May 2021 (UTC)[reply]

Github-wiki-bot inactive?

Hi, why has User:Github-wiki-bot no more contributions since August 2021? And more specifically, why did the bot not add the latest release 5.12.1 to Q2136131? I think the bot is very useful, would be nice if he would work again :) -Trustable (talk) 10:38, 8 October 2021 (UTC)[reply]

Hi, I've deactivated the job that runs the bot regularly because https://github.com/konstin/github-wikidata-bot/issues/139 kept crashing the bot and I don't have the time to fix that. IF someone fixes that bug, I'll activate the bot again. Konstin (talk) 10:42, 8 October 2021 (UTC)[reply]

Thanks for the fast reply. I see, it's blocked by the spam filter for a blacklisted URL. Sad, I hope this can be resolved.--Trustable (talk) 10:56, 8 October 2021 (UTC)[reply]

You should use try catch while processing each item.--GZWDer (talk) 16:02, 3 November 2021 (UTC)[reply]

Github-wiki-bot confuses Element iOS releases with Element Web releases when adding references to existing statements

In Element (Q47004029), Github-wiki-bot (talk • contribs • logs) adds references into existing software version identifier (P348) statements already containing the correct reference(s). The references added by the bot (onto existing statements I made) are incorrect for what I can tell, about 100% of the time.

Element does not release the entire code base for multiple platforms in a single repository. For example, the bot added a Web release reference to an iOS release statement (indicated by the platform (P400) being iOS (Q48493)) (which was removed)

The way the statements are formatted is based on existing statements before I started adding in releases constantly. The way it's also done makes the Wikipedia page on Element show the correct versions for the respective platforms (web and desktop versions could be merged into 1 statement but they still are separate repositories).

I have already removed some dubious references, but I haven't gone through them all.

I've added the item to the list of exceptions to avoid more dubious references for now. A solution that would make release adding automated for something like Element could be very helpful, but currently, it has some problems in some areas with the way it is working on Element (Q47004029). JacksonChen666 (talk) 21:00, 11 October 2022 (UTC)[reply]

Include copyright status (P6216)->copyrighted (Q50423863) whenever adding copyright license (P275)

I've noticed that Github-wiki-bot can add statements for the copyright license (P275) specified in a Github repository. For cases where you can infer that the repository is copyrighted from the use of the license alone (e.g. MIT license, 2/3 clause BSD license), could you also add the accompanying statement copyright status (P6216)->copyrighted (Q50423863)? This would address the item-requires-statement constraint on copyright license (P275). Harryboyles (talk) 20:37, 26 October 2022 (UTC)[reply]

GitHub wiki bot doesn't add what platform it is and whether it is stable

Despite the platform being specified for each repository, the bot still didn't add them to Q17590603 Aaron Liu (talk) 14:34, 5 November 2022 (UTC)[reply]

GitHub wikibot should not add official website (P856) to instance of (P31) website (Q35127)

Example Lectrician1 (talk) 23:52, 14 November 2022 (UTC)[reply]

Github-wiki-bot is replacing source code repository qualifiers with obsolete qualifier

Although source code repository URL (P1324) used to be used with the protocol (P2700) qualifier to indicate the version control system, some time ago that usage of protocol (P2700) was replaced by two new qualifiers, version control system (P8423) and web interface software (P10627), and most of the thousands of existing repository statements have since been converted to use the new qualifiers. However, it appears that Github-wiki-bot has replaced these on a few hundred statements with the obsolete protocol (P2700)Git (Q186055) qualifier, which is no longer valid; for example: https://www.wikidata.org/w/index.php?title=Q107385647&type=revision&diff=1758564220&oldid=1755307404&diffmode=source Apparently it doesn't like the optional .git suffix on the end of the URL. I see no issue with removing the .git suffix, but if it's going to do that can you please fix the bot to not mess up the qualifiers in the process? For a GitHub repository URL it should have qualifiers version control system (P8423)Git (Q186055) and web interface software (P10627)GitHub (Q364) and no protocol (P2700). A repository might also have other qualifiers like start time (P580) and end time (P582) that should be retained if present. Thanks. –LiberatorG (talk) 01:33, 16 November 2022 (UTC)[reply]

Thanks, I've created https://github.com/konstin/github-wikidata-bot/pull/166 --Konstin (talk) 18:27, 16 November 2022 (UTC)[reply]

Thanks. That looks like an improvement, although it still doesn't retain existing qualifiers like start time (P580) and end time (P582) that might be present on the original claim; the entire original claim, with all of its qualifiers, are just deleted. –LiberatorG (talk) 19:27, 16 November 2022 (UTC)[reply]

Do you have an example where the bot deleted those qualifiers? that would make debugging easier --Konstin (talk) 14:01, 23 November 2022 (UTC)[reply]

Ok I just checked and didn't find an example with P580 or P582 qualifiers, although I found several cases where the bot removed a reference from the source code repository claim when attempting to normalize the repository URL. A few random examples:

–LiberatorG (talk) 00:36, 24 November 2022 (UTC)[reply]

How to run / how often is it run?

I added some software about 10 days ago (hledger and ledger2beancount). The info for the GitHub repo is set.

I was hoping your bot would add the software releases, but this hasn't happened.

Can you add some instructions to the bot's page saying how often the bot is run (maybe I'm not patient enough but it has been 10 days already) and/or what needs to done for the bot to process a certain software (is it automatic? do I have to request it manually?)

Thanks. tbm (talk) 06:41, 20 December 2022 (UTC)[reply]

The bot runs once daily. The problem was the trailing slash in the github url, which now gets removed automatically. Konstin (talk) 11:28, 18 March 2023 (UTC)[reply]

Leaving out stable version qualifier

Somehow the Github Bot did not add the "stable version" qualifier to RSS Guard. I added it once manually. I noticed it, while reading Comparison of feed aggregators on Wikipedia. There might be other software affected by the same problem. Columbus240 (talk) 21:35, 28 December 2022 (UTC)[reply]

Yes, Visual Studio Code has the same problem. I also mentioned it below.

Regpath (talk) 04:19, 8 May 2023 (UTC)[reply]

Auto add qualifiers for Github URLs

Whenever a Github URL is detected, the bot should try to add qualifiers version control system (P8423)Git (Q186055), web interface software (P10627)GitHub (Q364) and copyright license (P275) to source code repository URL (P1324) whenever it can. RPI2026F1 (talk) 17:32, 5 January 2023 (UTC)[reply]

Auto mark releases as at least stable or prerelease

GitHub has the option of setting releases as prereleases. The bot should be able to automatically add the release type qualifier based on this. It should also add some qualifiers from source code repository, such as platform/applies to part. The nonexistent of qualifiers causes multiple releases to be selected in these pages Aaron Liu (talk) 15:23, 12 January 2023 (UTC)[reply]

I've checked the firsts five entries from that list, Q17590603, Q947786, Q777840, Q938375 and Q7318344 and for all of them the release/prerelease and date tagging was fine, but the problem was rather that there were zero or two preferred ranks. The bot tries to set the preferred and normal ranks on a best effort basis, but some cases are unfortunately not automatable (e.g. when there is a preferred rank on a version that is in wikidata and not on github than we keep that), sometimes the wikidata api throws errors when trying to fix the rank (i unfortunately have no idea why) and sometimes people to manual edits. if you have specific behaviors where the bot fails with the ranks that could be automated i can have a look at adding them. Konstin (talk) 11:52, 18 March 2023 (UTC)[reply]

@Konstin Thanks for responding! Actually, I have recently realized that the issue is that it doesn’t add platform qualifiers from the source repository field’s qualifiers. Could you add that? Thanks in advance! Aaron Liu (talk) 17:55, 18 March 2023 (UTC)[reply]

What do you mean by platform qualifiers? Konstin (talk) 21:32, 18 March 2023 (UTC)[reply]

For software with separate repositories for each platfrom/release type/whatever such as Material Design, each source code repository entry has a platform/release type/whatever qualifier. What I recommend is that for each repository the bot scans from, all of that repository's qualifiers (except archive url, start date and version control system) are added to the new release. Aaron Liu (talk) 22:47, 18 March 2023 (UTC)[reply]

Hi @Konstin, just making sure you received this? Aaron Liu (talk) 21:36, 19 March 2023 (UTC)[reply]

Yes that would be a useful addition Konstin (talk) 19:49, 20 March 2023 (UTC)[reply]

It does not add a qualifier 'version type' to Visual Studio Code

Thank you for making this wonderful bot. But it does not add the qualifier 'version type' of the Visual Studio Code Q19841877, so the latest stable version does not appear properly in the infobox of the main article w:Visual Studio Code. Regpath (talk) 07:11, 5 April 2023 (UTC)[reply]

I was going to report this. This is also occurred in nnn (Q69904311) file manager. Labdajiwa (talk) 01:52, 9 May 2023 (UTC)[reply]

It still happens as of July 8, 2023.

Regpath (talk) 09:32, 8 July 2023 (UTC)[reply]

You can add the qualifier in the repo, but at least i unfortunately won't get around to adding this any time soon. Konstin (talk) 15:03, 8 July 2023 (UTC)[reply]

Fixed in https://github.com/konstin/github-wikidata-bot/commit/616393d0538f7eaac44ddb96550df2d699d0d693 Konstin (talk) 17:58, 17 September 2023 (UTC)[reply]

💙🤖 love user:Github-wiki-bot

Thanks for making the bot and directing it to do so many useful edits for Wikidata's coverage of software in GitHub. Bluerasberry (talk) 18:50, 2 August 2023 (UTC)[reply]

<3 Konstin (talk) 17:55, 17 September 2023 (UTC)[reply]

Signal

Hello! First of all thank you for enabling the bot to check for Signal releases (Q19718090). Last year I did it manually for a while but it's very time consuming, given the constant release of new versions and devices.

I noticed however, that the bot "only" imports the newest version and sets the preferred rank. Unfortunately this makes a mess of the data presented in the Wikipedia English Infobox (the only one I checked), because there is no distinction between the devices and version types (Properties P:548 and P:400).

Would it be possible to update the bot to import these data as well?

Thank you in advance and kind regards, IrrationalBeing (talk) 19:07, 4 August 2023 (UTC)[reply]

I'm afraid signal is a special case that we can't automate, it's best to add signal to the bot excludes and update it manually instead. Konstin (talk) 17:54, 17 September 2023 (UTC)[reply]

Github-wiki-bot does not add "version type" (P548)

Good day @Konstin,

Your bot is doing a lot of good work. However we are missing "version type" (P548) for new items. And it is also resetting the "preferred rank" (Q71533031) flag of an older item, even if the version type for this version is "long-term support release" (Q15726348).

The version type value is needed for most Dutch (and maybe more languages) software related Wikipedia items to select the data (writen down in templates and widely used) resulting now in no or ancient information displayed.

So please update your bot.

Sincerely Ad Verburg (talk) 15:44, 5 August 2023 (UTC)[reply]

I've excluded long term support releases when resetting the preferred rank (https://github.com/konstin/github-wikidata-bot/commit/af24bc21982340584fec6a74b4d0d42398bef05b) --Konstin (talk) 17:26, 17 September 2023 (UTC)[reply]

Hi, @Konstin,

Thank you for your improvements.

For "Signal" (Q19718090), I had to make several manual corrections because we have three types of software here (Android, iOS and desktop), so that should be noted, and there may not be a "general" version.

Sincerely Ad Verburg (talk) 15:26, 21 September 2023 (UTC)[reply]

In that case please consider excluding Signal, that multiplatform is often a too complex case to handle for the bot Konstin (talk) 15:30, 21 September 2023 (UTC)[reply]

GitHub Wiki Bot should not add website after being reverted

In OpenSA (Q122202424) that is already covered by Mod DB mod ID (P8267). Don't start an edit war with me. Matthias M. (talk) 10:56, 19 September 2023 (UTC)[reply]

As documented, you can exclude pages. Konstin (talk) 11:15, 19 September 2023 (UTC)[reply]

You are causing additional work for me as a user. That is not what bots are designed for. It should detect a revert and automatically exclude pages. Matthias M. (talk) 17:02, 30 December 2023 (UTC)[reply]

Github-wiki-bot not updating item after resolving a conflict in source code repository URLs

Hi Konstin, I'm running into an issue with Github-wiki-bot. The source code repository URL https://github.com/lightningnetwork/lnd was previously used both in Lightning Network (Q30325114) (incorrectly) and Lightning Network Daemon (Q109973286). Because in the latter it was added later, the bot never added version identifiers to it. However, even after I've removed the URL and identifiers from the former and waited a few days, the bot still hasn't added version identifiers to the latter item. Is this something that can be fixed in the code, or can you just manually trigger the bot to process Lightning Network Daemon (Q109973286)? Or should I remove and re-add the URL, assuming that would fix it?

Thank you for your work! AVDLCZ (talk) 23:53, 3 October 2023 (UTC)[reply]

After trying to parse the release names and tags, the bot only sees pre-releases on github (https://gist.github.com/konstin/5fe488efa2e09a6742d19ecef5456ae1), and we only add releases when we see at least one stable release. Konstin (talk) 13:29, 7 October 2023 (UTC)[reply]

Ah, that explains it, thanks! So it actually has nothing to do with the URL being incorrectly used multiple times. I guess I'll add the version identifiers manually then, it's probably not a great idea to have the bot try to figure out which projects are in a "permanent beta" and should have their beta releases included. AVDLCZ (talk) 05:16, 13 October 2023 (UTC)[reply]

Bot removes GitHub repository statements instead of appending

In this case it wants to append web interface software (P10627) and version control system (P8423), but instead of doing that it creates a new statement duplicating the entry and then removing the original one. [2] This is an improper implementation that should be fixed. Matthias M. (talk) 16:59, 30 December 2023 (UTC)[reply]

Good point, fixed in https://github.com/konstin/github-wikidata-bot/commit/efd805bead1b059b71e5ec464ea1c686a680d63d and tested on Q233515 (SCI Companion). Konstin (talk) 13:47, 13 January 2024 (UTC)[reply]

FONTLOG

it would be dandy if the Github-wiki-bot would parse FONTLOG.txt (official template). repos of typefaces usually don't have releases tagged in the git system, but often enough provide a version history and other metadata in a FONTLOG.txt, like in Comic Neue's case. Chewzy (talk) 00:52, 25 January 2024 (UTC)[reply]

Bot version update malfunction

Why does it keep doing this? Bender235 (talk) 20:28, 17 March 2024 (UTC)[reply]

Beats me. It keeps causing issues on many pages, such as this one. Judging from this Talk page, the bot constantly needs fixing. Like someone said back in 2018, it seems to be doing more harm than good. MichielN (talk) 21:13, 18 March 2024 (UTC)[reply]

It definitely shouldn't! There's a check to not change ranks when there is an preferred rank not matching a version from github, i've adjusted it again and hope it works better from now on. Konstin (talk) 23:11, 18 March 2024 (UTC)[reply]

Dead Link

This edit is incorrect. The Content of that Website is no longer available, "Website under construction". --Snoopy1964 (talk) 12:16, 2 April 2024 (UTC)[reply]

I looks like the project is dead; the website is still listed as official website on the repo. Given i don't see any new releases with the last commit being 7 years ago, i'd just add that repo to the blocklist. Konstin (talk) 12:21, 2 April 2024 (UTC)[reply]

Github-Wiki-Bot: Add bug tracking system (P1401)

It would be cool if the bot could add issue tracker URL (P1401) to entries as well, It's exposed in the api if its enable or not as "has_issues": true (example with enabled, disabled), The issues url is always $projecturl/issues if its enabled. P858snake (talk) 02:01, 14 April 2024 (UTC)[reply]

Q125464173

Please stop adding Google Play as official website Trade (talk) 07:39, 2 May 2024 (UTC)[reply]

The bot is adding it as website due to https://github.com/google/google-authenticator-android linking it as website. You can add the page to exclusion to prevent the bot from making the edit. Konstin (talk) 07:42, 2 May 2024 (UTC)[reply]

No clue how to do that Trade (talk) 12:18, 3 May 2024 (UTC)[reply]

By adding it to User:Github-wiki-bot/Exceptions in a Q<id> # <reason> format Konstin (talk) 12:20, 3 May 2024 (UTC)[reply]

We can't do that for every new software. You need to blacklist this type of URL yourself to cover all the cases. Matthias M. (talk) 21:08, 24 May 2024 (UTC)[reply]

Could you clarify what url pattern for the website you want exluded, and why it is not the official website even if it is listed as such on github? Konstin (talk) 09:06, 25 May 2024 (UTC)[reply]

When the website is not the official website but a project website somewhere else with a stable ID they get their own property. Your bot needs to be able to ignore all the patterns on Property talk:P856 to avoid conflicts. Matthias M. (talk) 09:38, 25 May 2024 (UTC)[reply]

Thanks, added the url pattern as excludes in https://github.com/konstin/github-wikidata-bot/commit/9aed2477cebb69d0f796886474733e9298c8eed3 Konstin (talk) 07:38, 26 May 2024 (UTC)[reply]

Please stop adding Gamejolt as website

It is constantly removed by another bot in A Village in the Sky (Q123118612) for example. Matthias M. (talk) 21:07, 24 May 2024 (UTC)[reply]

Fixed in https://github.com/konstin/github-wikidata-bot/commit/9aed2477cebb69d0f796886474733e9298c8eed3 Konstin (talk) 07:39, 26 May 2024 (UTC)[reply]