User talk:Larivact

From ArchWiki
Latest comment: 18 May 2023 by PolarianDev in topic Deletion of closed discussion

Link checker


I've noticed that you've been updating many links lately to use HTTPS and flagging dead links, thanks! Are you doing all the work manually or do you have some tool helping you?

-- Lahwaacz (talk) 17:28, 2 June 2017 (UTC)Reply

I have to admit that I was doing it manually. Forgive me, Father, for I have sinned.
I just wrote a small Python script that detects dead links and HTTP links that can be upgraded to HTTPS. Cheers.–Larivact (talk) 21:06, 2 June 2017 (UTC)Reply
No worries, better late than never :-) As for your comment on automatic editing, that would be obviously very nice and I might even help you with that. Here is my, which currently checks internal links and only a few external links and (semi-)automatically makes the edits. If you'd like, feel free to try it, only know that there are still many false-positives that should be handled differently than what the script suggests, so use the --dry-run option for testing. Also, since there is practically no documentation, feel free to ask anything.
As for the checking strategy, I think that if the updates are fully automated, the script should be able to detect and ignore temporarily unavailable sites. For example, if we run the script daily, it should flag dead links only on the second or third successive failure. For that we would need to have some persistent cache of the responses, so that would be much more difficult though.
-- Lahwaacz (talk) 07:08, 3 June 2017 (UTC)Reply
I uploaded my current version. It seems to work fine except that it fails to recognize identical dead links in man templates. I am not sure how to fix this. Maybe earwig will have an idea. [1]Larivact (talk) 20:47, 3 June 2017 (UTC)Reply
I put my bot on ice till there is a Python MediaWiki parser that supports space-initialized code blocks. It doesn't look like earwig cares about #103. --Larivact (talk) 12:41, 29 June 2017 (UTC)Reply

API login

According to the MediaWiki docs you should get a login token from action=query&meta=tokens and post to clientlogin. action=query&meta=tokens however returns +\ as the token when I am not logged in. --Larivact (talk) 06:23, 17 June 2017 (UTC)Reply

Apparently it's the edit token for anonymous users and you need to send a valid _session cookie to log in. So you need to be logged in in order to log in ... that's just stupid. --Larivact (talk) 07:45, 17 June 2017 (UTC)Reply
The meta=tokens submodule has an additional type parameter, where you should pass login. You might be more happy with this documentation as a complete API reference. -- Lahwaacz (talk) 08:24, 17 June 2017 (UTC)Reply
token=$(curl "$api=query&meta=tokens&type=login" | jq -r .query.tokens.logintoken)
curl --data-urlencode "logintoken=$token" "$api=clientlogin"
I get a badtoken error. --Larivact (talk) 09:40, 17 June 2017 (UTC)Reply
Now hook up the cookies:
token=$(curl "$api=query&meta=tokens&type=login" -c test.cookie | jq -r .query.tokens.logintoken)
curl --data-urlencode "logintoken=$token" "$api=clientlogin" -b "archwiki_session=$(tail -n 1 test.cookie | awk '{ print $7 }')"
At least it gives me a different error now ;)
-- Lahwaacz (talk) 11:29, 17 June 2017 (UTC)Reply
"You're not allowed to edit this wiki through the API" Discriminating bots, huh? --Larivact (talk) 13:48, 17 June 2017 (UTC)Reply
Not bots, only new accounts. As shown couple of lines below, you need at least 20 edits and 3 days of age. Sorry for the inconvenience, the config was designed against spammers rather than for bots. Also note that technically there are still only 3 bot accounts. -- Lahwaacz (talk) 14:11, 17 June 2017 (UTC)Reply

Moving articles to User space

Hi, thank you for moving articles without content back to the authors' User pages, if I can suggest an improvement you could also update or remove any backlinks in doing so, cheers :) -- Kynikos (talk) 11:17, 13 August 2017 (UTC)Reply

Of course, thanks for cleaning up after me. --Larivact (talk) 11:38, 13 August 2017 (UTC)Reply
Hi, scrolling recent changes here, I'm not sure about a couple of moves today. For example, User:Thestinger/Nessus. It has a dozen contributors over years, software is uptodate & article covers some specific info, a Nessus_(Русский) translation exists too. Why does it not have enough flesh to stay in Main? --Indigo (talk) 19:14, 17 August 2017 (UTC)Reply
Hi, the installation note is superfluous, if you are interested in how a PKGBUILD file works, read it; when a PKGBUILD does a silent HTTP request this should be fixed. The post-installation setup section is unnecessary as the localhost page tells you to do that anyway. The service name and the localhost URL are echoed in post_install. The removal note should be echoed in post_remove. So the few info that's there can just be echoed during installation / removal and doesn't require an article. I now commented my suggestions at the AUR package.[2] --Larivact (talk) 05:25, 18 August 2017 (UTC)Reply
Thanks, all good reasons, and good move to suggest the improvements to the AUR package. Yet, consider the following: (1) How did you come up with the improvements for the PKGBUILD? Without installing the package or scrolling years of comments, the info in the article helped you. You sure are right it is better served in the PKGBUILD, but it is not there yet - and if you did not explain here, the move reasons would not be transparent. (2) What may happen in six months, if another user sees there is no article on Nessus yet? S/he may create one from scratch, rather than improving an existing (fixing style and removing then superfluous info), or reconsider after finding the previous one via a Template:Archive). (3) Since User pages are not indexed in our search, there is no direct way to find the current one. Moving it like this also leaves translator teams in a flux figuring why the original is gone.
I'm appreciating your effort to clean-up too, please don't think otherwise. I'd like to make another suggestion: We have Template:Stub and want to archive it. The problem is that it is still used in many articles, Special:WhatLinksHere/Template:Stub. Among these will be clearer cut candidates for archiving/Template:Merge for otherwise useful info/move to user space (the latter should be primarily for articles a single contributor started but never got round to bringing it to a full article). Cheers. --Indigo (talk) 08:28, 18 August 2017 (UTC)Reply
Thanks, I wasn't aware of the confusion I caused. I moved the articles to the User namespace since I didn't get archiving - I thought it was a dedicated feature. I'll undo my recent moves. --Larivact (talk) 18:27, 18 August 2017 (UTC)Reply
So do we have a uniform strategy on when to Archive something and when to move something back to the original author's user page? E.g. [3], [4], [5] would fall under the above "single contributor" criterion...
Also I'll take advantage of this to remind ourselves of the behemoth discussion ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F which is not yet completed. -- Alad (talk) 18:55, 18 August 2017 (UTC)Reply
I'd say if it has only one contributor (excluding translators adding language links, bot edits etc.) and it is not very old (e.g. up to 1 or 2 years), then move it to the user namespace, otherwise archive it. -- Lahwaacz (talk) 19:36, 18 August 2017 (UTC)Reply
Sounds good to me. While it can get arbitrary, I'd also exclude simple fixes done by staff to help a new article to par style-wise.
@Larivact: thanks again. --Indigo (talk) 17:10, 19 August 2017 (UTC)Reply
I agree too with Lahwaacz's proposed guidelines, we can make them official in Help:Procedures#Remove an entire page. Sorry I don't have time to resume ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F at the moment. -- Kynikos (talk) 09:39, 20 August 2017 (UTC)Reply
I'd make it depend on the current amount/quality of information. When something is only a short stub / a style mess it's not really worth archiving. On the other hand when we deal with all such pages and monitor new pages the two year rule should work.--Larivact (talk) 15:13, 23 August 2017 (UTC)Reply
Also note that when a page has dozens of contributors and it's still "a short stub / a style mess", it's not really worth moving to the subpage of the first editor. If something's not worth archiving, we might as well delete it. -- Lahwaacz (talk) 16:43, 23 August 2017 (UTC)Reply
I've started deleting pages that are either irrelevant to Arch (e.g. ArchAudio which was some random third-party project, now dead) or are "stubs" without meaningful contribution (e.g. Bankid). @Larivact: great work on the categorizing/cleanup you're doing btw. -- Alad (talk) 10:29, 24 August 2017 (UTC)Reply
N.B. If there's a related page (such as a modern replacement), it's likely better to redirect pages there rather than delete or archive them. All this does show there's gaps in Help:Procedures#Remove an entire page and I agree to expand it. -- Alad (talk) 10:36, 24 August 2017 (UTC)Reply
I absolutely don't want to duplicate ArchWiki talk:Administrators#Should we remove or archive obsolete articles? here, but my position is that for the moment the issue is regulated by Help:Procedures#Remove an entire page which only considers deletion in case of "spam or other clearly malicious content". I think that all contributions that made it to stay published for long periods (ArchAudio even since 2009) are part of the history of the wiki and should not be deleted. I don't see the advantages of deleting except when in need to censor the content; the data is not actually removed from the database, so it's not even a relief for the server, as small as it would even be, and I still regret having the habit of deleting pages and especially discussions before the only (and I hope last) occasion in which the deleted articles were actually purged from the database without any warning. -- Kynikos (talk) 17:40, 26 August 2017 (UTC)Reply
In the case of ArchAudio I would say it never belonged on the wiki in the first place, or classifies as spam. See [6] which raised the original concern but was closed arbitrarily by two users. In the other cases I agree they might as well have been moved back to the user namespace. -- Alad (talk) 12:54, 27 August 2017 (UTC)Reply
Topic is closed but I do think some pages should redirect/merged to List of applications. I am now reviewing pages moved to user namespace and do the work if approprite. -- Fengchao (talk) 06:13, 5 September 2017 (UTC)Reply

Weird API behavior

Requesting yields no revisions for some pages (eg. CUPS).

--Larivact (talk) 09:39, 23 August 2018 (UTC)Reply

Why do you include the rvcontinue= and continue= parameters? It seems to work fine without them. -- Lahwaacz (talk) 10:50, 23 August 2018 (UTC)Reply
I am implementing query continuation for a script. Apparently querying is limited to 50 pages (or 500 with apihighlimits).[1] Interestingly the MW API returns no warning whatsoever when you overdraw that limit and just silently stops returning requested properties for pages and the returned continue yields the same pages again but with different pages having/lacking the properties.[7] Thanks anyway for the prompt reply.
--Larivact (talk) 15:03, 23 August 2018 (UTC)Reply
Well, I still don't see how you got to the rvcontinue parameter, because you can't combine the gbllimit and rvlimit parameters... But yeah, you can get pages without any properties in cases where you need to continue the outer pageset as well as the set of properties of each page. See the note in [8] and code in [9], maybe it will help. -- Lahwaacz (talk) 08:10, 24 August 2018 (UTC)Reply
You get rvcontinue in continue if you request my last link without cookies. --Larivact (talk) 09:19, 24 August 2018 (UTC)Reply

Welcome back

:) -- Kynikos (talk) 14:19, 30 December 2018 (UTC)Reply

Help procedures

Hi, I was patrolling yesterday and that included your draft merging to the dotfiles article. As far as I'm concerned you did a fine rewrite of the sections, but I had problems to follow-through changes and ended up doing a time consuming side-by-side. I skip details right now (unless you have immediate remarks or questions), but conclude that it was on the verge of having to void said merge; always a pity when due to technicalities. A follow-up conclusion for me is that we shall work on clarifying technicalities. If noone is faster, I will open a general talk item in Help talk:Procedures sometime soon to figure which merge procedures need to be clarified/created to ease related editing. I hope to get your input there. --Indigo (talk) 18:43, 26 January 2019 (UTC)Reply

We already have ArchWiki:Contributing#Do not make complex edits at once. I don't think further elaborations are necessary — I redid my merge in 5 edits. I don't see how my merge violates the GFDL. --Larivact (talk) 15:41, 27 January 2019 (UTC)Reply
Well, I agree to far that it is difficult to judge how much elaboration is useful in the Help namespace, considering breadth of wiki experience and other factors (e.g. language skills) of contributors. So, I've opened Help_talk:Procedures#Merge procedures to gauge further opinions.
For reference: dotfiles before and after merge 1 (e.g. the redlink violates GFDL section 4.J.), merge 2. Easy example: For both merges, put yourself into the eyes of another article contributor who wonders what happened to the etckeeper listed before. --Indigo (talk) 19:27, 27 January 2019 (UTC)Reply
What redlink do you speak of? 4J does not appear to be relevant. I am not manually recreating every edit. --Larivact (talk) 19:33, 27 January 2019 (UTC)Reply
Nice you did the extra step. I did not intend that, but raise awareness why I believe it's necessary to work more on a good, general way to handle complex mergers. Next, the section 4J example: "4 Modifications J. Preserve the network location" - the edit summary redlink equates to a non-preserved network location, that's as straight-forward as it gets. (Btw, section 4.I. above it defines the term "history" == MW "history" tab per article.). Ok? --Indigo (talk) 21:04, 29 January 2019 (UTC)Reply
Do you understand my answer? --Indigo (talk) 10:16, 10 February 2019 (UTC)Reply
You seem to be misunderstanding the GFDL. User:Larivact/drafts/Dotfiles was the correct network location at the time, that it is no longer accessible is unfortunate but the very nature of network locations. Also:
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
--Larivact (talk) 10:30, 10 February 2019 (UTC)Reply


hi i have a question, should we use mono or italic (like jwm or i3) for manual xorg wm start? --Ubone (talk) 14:42, 4 February 2019 (UTC)Reply

Monospace as per Help:Style/Formatting_and_punctuation#Executable/application_names. --Larivact (talk) 14:53, 4 February 2019 (UTC)Reply


Added a proposal on Talk:limits.conf, please share your thoughts at your convenience. Thanks! Chowbok (talk) 00:18, 6 August 2019 (UTC)Reply

Deletion of closed discussion


I am just here to remind you that the following discussion has not yet been deleted, and has been closed for 7+ days:

Talk:Mail_server#Checklist draft

Thank you, PolarianDev (talk) 23:23, 15 March 2023 (UTC)Reply

I have deleted the discussion as it has been 2 months since I have made this discussion to ask you to remove it (as it was your discussion).
I am closing this discussion as it is completed, PolarianDev (talk) 10:41, 18 May 2023 (UTC)Reply