User talk:Lahwaacz
bot checking links after move
Hi, re Talk:Touchpad Synaptics#adding libinput alternative. Touchpad Synaptics has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of Touchpad Synaptics and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --Indigo (talk) 07:36, 26 September 2015 (UTC)
- Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a UUID page, which was later generalized and renamed to Persistent block device naming and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace [[pacman|Install]] with [[Install]] etc. -- Lahwaacz (talk) 08:01, 26 September 2015 (UTC)
- Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [1]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --Indigo (talk) 10:02, 26 September 2015 (UTC)
Automatic template correction
Per Help:Template#Style, templates should be used with the capitalization shown in the examples in their pages, so {{AUR|...
is correct, while {{aur|...
is not.
However, there are pages that don't respect that rule (e.g. Android_Debug_Bridge until recently).
I beleive this correction should be easy to implement using a bot. What do you think?
—This unsigned comment is by Relrel (talk) 07:24, 25 August 2020. Please sign your posts with ~~~~!
- Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a style linter for the ArchWiki rules. Would you like to help? ;-) – Lahwaacz (talk) 09:21, 25 August 2020 (UTC)
Readability in Wiki
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks. For example in the introduction of Wayland.
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people. I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.
G3ro (talk) 14:38, 15 October 2020 (UTC) G3ro
- I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- Lahwaacz (talk) 19:15, 15 October 2020 (UTC)
- Well I guess it can be about both. But mainly it is about what people see on the page.
- There are three seperate topics I mentioned:
- 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.
- While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.
- 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.
- 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.
- G3ro (talk) 20:33, 15 October 2020 (UTC) G3ro
- OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the <br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.
- Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for Wayland, the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.
- As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.
- If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.
- -- Lahwaacz (talk) 20:59, 15 October 2020 (UTC)
Root on ZFS draft
Hi, I submitted a Root on ZFS draft to official doc repo.
In the draft, the following directories are separated from root filesystem:
home,root,srv,usr/local,var/log,var/spool,var/tmp
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft? Any comment is appreciated. M0p (talk) 01:28, 23 January 2021 (UTC)
Network configuration edit
Hello
You reversed my edit in the network configuration pages (https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=next&oldid=788365) because you stated it was out of scope and tlsv1.0 is insecure
I disagree on the first part, many people I know, I first have struggled to configure eduroam on archlinux and this place seems the best fitted
On the second part, I agree tlsv1.0 is outdated and insecure, sadly it's the one used in some schools Ultraxime (talk) 17:11, 4 October 2023 (UTC)
VCS revert
https://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=0&oldid=802958
While the VCS page isn't about AUR, I feel that the short Note about not bumping up pkgver needlessly is still a welcome addition to it, and additionally linking to the AUR policy is a fine crosslink.
C0rn3j (talk) 15:42, 11 March 2024 (UTC) C0rn3j (talk) 15:42, 11 March 2024 (UTC)
- You can already link to the note in Arch User Repository#Flagging packages out-of-date. — Lahwaacz (talk) 16:58, 11 March 2024 (UTC)
- That's exactly the note I linked, VCS package guidelines for AUR deserve such a footnote on this page.
- Just today I went to link the VCS page to a friend confused about -git packages, only to again find out that's exactly the page that is missing any kind of mention about it.
- Please reconsider. C0rn3j (talk) 11:58, 22 May 2024 (UTC)
- You should just direct people to Arch User Repository#Flagging packages out-of-date. The VCS package guidelines page is not about the AUR out of date button and the upgrade process. — Lahwaacz (talk) 10:51, 22 June 2024 (UTC)
Install Arch Linux on a removable medium
Its not an edge case, there is still plenty of BIOS machines. Real edge case is a person who installs arch on USB stick :) it is not a general advice, please read it again carefully.
https://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&oldid=815197 Omeringen (talk) 16:14, 24 August 2024 (UTC)
Workaround to use suspend-then-hibernate with GNOME on lid close
You reverted my message stating 'systemctl suspend-then-hibernate works on GNOME'. (It's the last contribution on my user profile)
Of course you can run 'systemctl suspend-then-hibernate' but as I described, there is no way to trigger a suspend-then-hibernate from GNOME. I found a neat way to trigger this anyway and that's what I describe. I thought this trick would be of interest to other people so I thought about contributing and sharing it on the Arch Wiki. Do you disagree that this would be useful information. If so, why? Or might this be of interest on some other page? Starquake (talk) 13:48, 21 October 2024 (UTC)
- What I meant is that you can run the
systemctl suspend-then-hibernate
command even on GNOME. If you are missing a graphical button somewhere, it can't be considered part of the "support in GNOME" and it is not really relevant on the Power management page. — Lahwaacz (talk) 12:41, 27 October 2024 (UTC)- Okay, thanks, I'll see if this would be useful to mention on some other page. Starquake (talk) 17:36, 27 October 2024 (UTC)
makepkg documentation update on correct usage git+http
""unmirroring" a git repository is not a thing" if you think so then please create PKGBUILD file with git+https://gitlab-ci-token:<token>@gitlab.com/project.git
you will see immediately that "project" folder contains mirror because git.sh script is cloning with --mirror option. Next internal step after cloning is going to fail with message about its not git repository. To solve this issue you have to at [new_name]::git+http... to be clone from bare to normal mode. Reason why I love arch linux and use it since 2015 commercial is Wiki. Wiki should be up to date and this is my contribution. Please reconsider undo once more.
I literally hit the same problem while rebuilding my custom package and spend hour trying to figure out how to solve the problem which in my opinion should be covered by the Wiki.
https://unix.stackexchange.com/questions/154919/how-to-modify-a-pkgbuild-which-uses-git-sources-to-pull-only-a-shallow-clone Note: now /usr/share/makepkg/source/git.sh should be patched instead that one of popular answers. Lukaszdh (talk) 15:25, 24 November 2024 (UTC)
- I cannot reproduce your issue and can't tell if the problem is about the
[new_name]::
prefix or something else. There are definitely many existing packages that don't have the prefix and still work. Can you show your full PKGBUILD and the error output you are getting? — Lahwaacz (talk) 15:41, 24 November 2024 (UTC)- From obvious reason I can not share with you repository I've made sample repo which use same principal.
- https://gitlab.guns4hire.cc/lukasz.busko/lahwaacz/-/blob/master/pkg/PKGBUILD?ref_type=heads
- I was not able to reproduce the issue so it seems that it somehow it is gitlab issue.
- The weird thing is that for actual project we are currently getting bare repo instead of normal one every time when attempt is to use PKGBUILD with out <what_ever_name>::. I will update this topic in a few days will try to redo production repo maybe it's gitlab issue after all. Lukaszdh (talk) 21:42, 24 November 2024 (UTC)
- Well this repo works just fine for me: I could run makepkg with no issues so it is not a GitLab issue either. What is the version of the tools you are using? — Lahwaacz (talk) 21:53, 24 November 2024 (UTC)
- Hey, sorry for delay was very busy. So at the end it looks like gitlab repository issue. When I add next origin for current local repository and then push and clone imagine problem does not exist anymore. Lukaszdh (talk) 23:07, 30 November 2024 (UTC)
- Well this repo works just fine for me: I could run makepkg with no issues so it is not a GitLab issue either. What is the version of the tools you are using? — Lahwaacz (talk) 21:53, 24 November 2024 (UTC)