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)

Python packaging guidelines: Unpacking wheels

You removed the tip I added in the Python packaging guidelines regarding unpacking wheels, noting the packaging guidelines pages are to be modified by Package Maintainers only.

• I nonspecifically recall previously being advised to offer a more concrete edit for consideration, this was me overcorrecting in the other direction. To avoid a third reiteration, could you please explain what the expected editing procedure is for edits of this scale? I eg see no mention of such a PM-only policy in ArchWiki:Contributing or Help:Editing
• Accepting that my edit may have been against policy -- was there anything substantively wrong with my edit? Or was it merely removed because I had violated policy? In particular, what is blocking restoring it to the page?

Thanks, Gesh (talk) 19:39, 26 January 2025 (UTC)

Hi, the guidelines are supposed to be authoritative even for official packages so major changes need to be discussed and accepted by the team before adding them to the page. The talk page should be used for this purpose, you can draft the addition and have it reviewed by others. Even though your idea was probably not to change the direction of the guidelines, the wording should be much better to document the status quo without potentially arguable recommendations. You can find my view on this by reading the recent comments in Talk:Python package guidelines#Using virtualenvs for tests, doc generation. — Lahwaacz (talk) 21:08, 26 January 2025 (UTC)

SpiderOAK: Don't list date on app list

Hi, thank you for reverting the edit, as it was not what is usually done on that page. I had made that comment because people might consider SpiderOAK with the idea of it being save, private, and secure; but it seems to not be maintained anymore to say the least. Adding the latest-update-date was a way of indicating that the service might not be what it seems. I am fine with leaving the date out; I just wanted to explain why I had put it there.

—This unsigned comment is by Lquidfire (talk) 12:57, 22 February 2025 (UTC). Please sign your posts with ~~~~!

I see you've adopted the AUR package and added a pinned comment, which is the right way to do it. — Lahwaacz (talk) 12:23, 28 February 2025 (UTC)

Is "Don't start with a warning" a general rule?

On Btrfs regarding my last edit you corrected the positioning of the warning with the comment "Don't start with a warning".

Can I consider this a general rule of style or was your correction specific to that case? I'm asking because there are at least 7 other topics in the same article that start with a warning. Or should the positioning of the other warnings be altered too?

My reasoning was to put the warning at the top because the user should know before he tries out the deletion command.

No offense, I'm just trying to learn the style of the wiki. Multifred (talk) 23:43, 2 March 2025 (UTC)

It doesn't make much sense to expect the reader to know what the section is all about just from the title and jump right into a warning. So yeah, the other sections should be checked as well. — Lahwaacz (talk) 06:10, 3 March 2025 (UTC)