User talk:Lahwaacz

From ArchWiki

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)

mkosi

Hi, about your revert: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- Nudin (talk) 11:33, 1 October 2017 (UTC)

Alright, how is the "more" relevant to systemd-nspawn though? -- Lahwaacz (talk) 17:30, 3 October 2017 (UTC)
Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- Nudin (talk) 22:23, 5 October 2017 (UTC)

Waking from suspend with USB device

Hi Lahwaacz, thanks for your input on this topic. Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [2]. In my case all the driver/*/power/wakeup are all enabled by default and the /proc/acpi/wakeup as well. Anyway I have added a step in my explanations to identify the path awaiting for more clarity.

Kewl (talk) 21:57, 16 January 2018 (UTC)

Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default:
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled
But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.
-- Lahwaacz (talk) 19:14, 19 January 2018 (UTC)

Are supported local/remote destinations important for choosing a backup program?

You reverted my edit adding supported backup destinations to Synchronization_and_backup_programs. This is puzzling to me. Here are some thoughts:

  • if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.
  • Given this, I am very puzzled you would use the term "useless" in the revert message.
  • I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"
  • On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.

Jernst (talk) 17:38, 11 June 2018 (UTC)

No because you can use any remote back-end with any backup application by just running one command / writing the backups to a FUSE (if available).--Larivact (talk) 04:39, 12 June 2018 (UTC)
Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? —This unsigned comment is by Jernst (talk) 18:08, 12 June 2018‎. Please sign your posts with ~~~~!
Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --Larivact (talk) 18:47, 12 June 2018 (UTC)
If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. Jernst (talk) 18:54, 12 June 2018 (UTC)

The pip section in Python package guidelines

Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – flying sheep 08:17, 8 March 2019 (UTC)

Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- Lahwaacz (talk) 19:21, 8 March 2019 (UTC)
That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – flying sheep 11:41, 11 March 2019 (UTC)
If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- Lahwaacz (talk) 13:26, 11 March 2019 (UTC)
Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?flying sheep

wpa_supplicant

Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:

https://bbs.archlinux.org/viewtopic.php?id=244950

It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?

--

Pooryorick (talk) 08:24, 18 July 2019 (UTC)

F2FS and GRUB

Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't.

If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.

Eurydice (talk) 00:17, 8 September 2019 (UTC)

The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- Lahwaacz (talk) 06:29, 8 September 2019 (UTC)
You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) Eurydice (talk) 19:37, 8 September 2019 (UTC)
The root= parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. grub-mkconfig automatically detects the root filesystem and adds the appropriate root= parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- Lahwaacz (talk) 20:02, 8 September 2019 (UTC)
It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. Eurydice (talk) 05:38, 9 September 2019 (UTC)

dracut executable link

Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the executable link just points to the top of the Help:Reading page.

—This unsigned comment is by Krathalan (talk) 17:06, 28 January 2020‎. Please sign your posts with ~~~~!

In that case your browser probably does not work correctly, because the redirect really points to the section. Or MediaWiki, there was a bug several years ago... -- Lahwaacz (talk) 19:41, 28 January 2020 (UTC)
How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. Krathalan (talk) 19:51, 28 January 2020 (UTC)

Getting install.php work in DokuWiki

Hi, than you for having undone my contribution and pointed to the right solution on Dokuwiki#Configuration. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?

Also, I think that, at the end of this same section, one should add something like "verify that php-gd is installed and restart php-fpm.service".

Naturally I can do it myself, but I prefer to ask before. BDumont (talk) 17:31, 19 February 2020 (UTC)

Hi, apparently it depends on whether you had open_basedir set previously or not. I've changed the page, feel free to update the gd extension. -- Lahwaacz (talk) 21:16, 19 February 2020 (UTC)
Thank you! However, while, I didn't have open_basedir set previously, I couldn't access install.php. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is open_basedir. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. BDumont (talk) 08:20, 20 February 2020 (UTC)

Double linefeed results in extra line

If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.

It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.

Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.

-- Svito (talk) 16:30, 11 May 2020 (UTC)

If this is about [3], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- Lahwaacz (talk) 20:41, 11 May 2020 (UTC)
OFC, I mean the template page render has extra line. -- Svito (talk) 21:21, 11 May 2020 (UTC)
I agree with Svito, isn't it good to delete the extra blank lines? -- Blackteahamburger (talk) 05:39, 12 May 2020 (UTC)
OK, let's do it. [4] -- Lahwaacz (talk) 16:47, 26 May 2020 (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)

Failed to create tun device

I don't understand your reason for [removing my section in NetworkManager]. Could you elaborate?--Egils (talk) 07:40, 11 September 2020 (UTC)

You can't use systemd-networkd and NetworkManager at the same time. Even if you don't have any .network file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- Lahwaacz (talk) 07:43, 11 September 2020 (UTC)
Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--Egils (talk) 22:27, 11 September 2020 (UTC)
You should really fix the permission problem for networkmanager-openvpn. The tun interface should be managed by OpenVPN which needs rights to create it. -- Lahwaacz (talk) 06:37, 12 September 2020 (UTC)
I don't think this statement is entirely correct. systemd-networkd and NetworkManager can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use NetworkManager on my laptop to handle wifi, while systemd-networkd is in control of virtual ethernet and bridges for all my systemd-nspawn instances. Romstor (talk) 03:24, 12 September 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)

SSHFS - systemd edit

The edit was removed because "there is no advantage over using fstab entries".

Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.

Reconsider the edit as it presents another option which people can use.

Garnica (talk) 16:22, 22 October 2020 (UTC)

There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: systemd.mount(5). But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- Lahwaacz (talk) 19:22, 22 October 2020 (UTC)
It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. Garnica (talk) 08:08, 24 October 2020 (UTC)
You can configure systemd targets in fstab using the x-systemd.wanted-by and x-systemd.required-by options, there are also nofail and noauto options. Please read the systemd.mount(5) manual.
Using hosts from the user's .ssh/config is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full user@hostname into fstab and you're done.
-- Lahwaacz (talk) 08:47, 24 October 2020 (UTC)

Self-encrypting drives

Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90

All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, Przemub (talk) 13:34, 28 October 2020 (UTC)

OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- Lahwaacz (talk) 14:27, 28 October 2020 (UTC)

Nvidia Installation

The whole guide is unnecessary long and overcomplicated formulated. Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.

G3ro (talk) 20:21, 10 November 2020 (UTC) G3ro

Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- Lahwaacz (talk) 20:36, 10 November 2020 (UTC)

Btrfs layout

Hi, Lahwaacz

Thanks for maintaining Snapper! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.

Cheers, I2Oc9 (talk) 07:26, 3 December 2020 (UTC)

It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in Snapper#Suggested filesystem layout. -- Lahwaacz (talk) 08:24, 3 December 2020 (UTC)
Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.I2Oc9 (talk) 09:02, 3 December 2020 (UTC)
Since last message I've extensively documented the new layout at User:I2Oc9/Btrfs_subvolumes and User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption. Have a look for yourself. Nothing new really, but IMO my take is much more simpler and complete than the supposedly simpler one. That one does not leverage native snapper rollback or grub-btrfs, among other things. I strongly suggest you try if you have time. I2Oc9 (talk) 11:55, 3 December 2020 (UTC)
Actually if you look closely, none of my recovery methods is specific to the new 'complex' layout, it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.
On the other hand, the layout recommendation has been updated by openSUSE [5], why stick with the old one? I2Oc9 (talk) 12:37, 3 December 2020 (UTC)
The main reasons why I reverted your edits on the Snapper page are: 1) it was a huge change which was not discussed previously as required by ArchWiki:Contributing#The 3 fundamental rules, and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in Talk:Snapper first. Your user pages would serve as great drafts.
Note that the current suggested layout is not flat in the sense of your section - it has a separate subvolume for .snapshots so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at /, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that the subvolume configuration must not be changed for rollbacks to work.
Now the openSUSE-specific elements: some Arch packages actually install software into /opt, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at /var/lib/pacman/local/ and it must be rolled back along with the system, so there should be no separate subvolume for /var. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under /var, such as /var/log, /var/tmp, /var/cache/pacman, /var/lib/machines, etc.
Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.
-- Lahwaacz (talk) 09:31, 4 December 2020 (UTC)
Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.
Yes, I get that the current layout is not the one described in this section and indeed properly separates /.snapshot and /. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.
As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted /boot on Btrfs on LUKS1, I really didn't think of any other possibilities.
I will incorporate your recommendations to my user page and add a new section in Talk:Snapper pointing to those pages.
Cheers -- S0x9v (talk) 10:09, 4 December 2020 (UTC)
I've adopted Archlinux Root on ZFS layout to my proposal. S0x9v (talk) 10:56, 4 December 2020 (UTC)

firefox zoom

"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work Ubone (talk) 02:38, 26 December 2020 (UTC)

That should be explained in HiDPI#Firefox anyway. -- Lahwaacz (talk) 10:48, 26 December 2020 (UTC)
it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" Ubone (talk) 15:51, 29 December 2020 (UTC)

Intel GVT-g edits

Hello Lahwaacz,

I have noticed that you reverted one of the edits I have performed on Intel_GVT-g.

About this revert: Windows problems are out of scope

While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.

Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.

Ciao,

Wilcomir (talk) 09:14, 3 January 2021 (UTC)

Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- Lahwaacz (talk) 10:34, 3 January 2021 (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)

Re: undo GRUB - Common installation errors

Concerning your undo of Add the error message `Could not prepare Boot variable: No space left on device`) Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. ModProg (talk) 12:51, 25 January 2021 (UTC)

The error message is not specific to the /sys/fs/pstore/ filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- Lahwaacz (talk) 13:16, 25 January 2021 (UTC)
I did not find anything Arch specific, but this post about Debian helped: Post. I also found something about /sys/fs/efi/efivars/dump-* The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. ModProg (talk) 16:20, 25 January 2021 (UTC)
This wiki is Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a common installation problem. -- Lahwaacz (talk) 07:29, 26 January 2021 (UTC)
I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? ModProg (talk) 22:24, 26 January 2021 (UTC)

Kernel Compilation time

Reference: link

I don't think we should judge information by what is obvious to experts. People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile. I think it does not hurt anyone to make people aware of it.

G3ro (talk) 14:03, 6 February 2021 (UTC)

It is an unnecessary information without a definite answer which can even be searched elsewhere. -- Lahwaacz (talk) 14:23, 6 February 2021 (UTC)
I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.
Also do you search for the compilation time for every program you intend to compile? I don't.
Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it?
G3ro (talk) 14:36, 6 February 2021 (UTC)
If someone wants to compile the Linux kernel, they should obviously expect that it will take some time. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...
As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.
-- Lahwaacz (talk) 15:03, 6 February 2021 (UTC)

Re: Steam Needs to be online error

Reference: link

The problem here is that DNS resolution in general works already (yes even outside browsers), i.e.

dig media.steampowered.com

would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.

Additionally, at no point does Domain name resolution even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. Irimi1 (talk) 08:12, 22 February 2021 (UTC)

Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- Irimi1 (talk) 09:15, 28 February 2021 (UTC)
Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. systemd-resolved) instead of nscd.service fixes the problem? If not, then it's probably not due to DNS - nscd(8) actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- Lahwaacz (talk) 14:22, 28 February 2021 (UTC)
No worries. Using systemd-resolved for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the Arch forums. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- Irimi1 (talk) 14:51, 28 February 2021 (UTC)
Okay, so nscd allows to dis-/enable caching per service, and it’s indeed enabling it for hosts that makes it work. That’s weird though, since systemd-resolved has caching enabled by default, and using it for resolution didn’t make steam work for me. Leads me to think that I didn’t set it up correctly, although resolving via dig *did* work. Since steam depends on Name Service Switch, I tried resolving using getent manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- Irimi1 (talk) 15:39, 28 February 2021 (UTC)
Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use Template:Expansion for the missing details? Maybe someone can figure it out. -- Lahwaacz (talk) 17:44, 28 February 2021 (UTC)
Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- Irimi1 (talk) 17:56, 28 February 2021 (UTC)

Removal of website link

Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701

I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already. G3ro (talk) 20:02, 28 February 2021 (UTC)

The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- Lahwaacz (talk) 20:24, 28 February 2021 (UTC)
There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.
I can only repeat myself, that things don't always have to be made more complicated than necessary.
The official website is a central point which links to many more useful ressources, so it's one link for much information.
G3ro (talk) 20:34, 28 February 2021 (UTC)

Removal of bootia32.efi generation procedure from X205TA install page.

Those instructions were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. Tallero (talk) 05:07, 4 March 2021 (UTC)

If there is something wrong with the information on the general page, it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- Lahwaacz (talk) 18:16, 6 March 2021 (UTC)
I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the See also archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? Tallero (talk) 13:28, 7 March 2021 (UTC)
Well, the removed section was previously flagged with "Duplicates Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI"...
Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.
-- Lahwaacz (talk) 13:58, 7 March 2021 (UTC)

DPMS: "\033[9;0]"

Hi. It seems that you removed echo -ne "\033[9;0]" from DPMS

https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073

A DULG page and a U&L post brought me here.

May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in console_codes(4)]

Thanks.

—This unsigned comment is by PXf (talk) 05:23, 15 August 2021‎ (UTC). Please sign your posts with ~~~~!

Display Power Management Signaling#DPMS interaction in a Linux console with setterm says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — Lahwaacz (talk) 18:40, 15 August 2021 (UTC)

cow_*

Hi Lahwaacz. About the how/why issue (there will be no more <!-- -->). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? on my machine Darren "Un1Gfn" "PXf" Ng (talk) 08:18, 12 October 2021 (UTC)

It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying why the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — Lahwaacz (talk) 05:42, 13 October 2021 (UTC)
What about making it a subsection of "Troubleshooting" and renaming it to partition / too full? PXf (talk) 06:45, 13 October 2021 (UTC)
It's better to motivate it as a tip/trick rather than solve the problem after it happens. — Lahwaacz (talk) 08:48, 13 October 2021 (UTC)

Install Arch Linux via Docker

(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)

'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing

but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:

every Arch user should know pacman's article by memory


The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.

Oliver (talk) 17:40, 26 October 2021 (UTC)

We use the same convention on the Installation guide itself. They should read the pacman page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "install" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — Lahwaacz (talk) 17:59, 26 October 2021 (UTC)

Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p

Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds throw their children out of their nests to teach them to fly (or die); Humans raise their children first in a more gentle manor. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro? Oliver (talk) 18:25, 26 October 2021 (UTC) Btw, the big irony is, that I came back on editing this page, as I never finished my first installation when I started that page; and so I had to (again) look-up a lot of stuff, just to be in the 'oh yeah duh' kind of state; so I'm not just offering this suggestions because I think the user needs them, *I* even needed them :) and wanted to help my future self, to one of these days actually make the arch-transition :) (which you are not making any easier :p) Oliver (talk) 18:56, 26 October 2021 (UTC)

Minimizing disk access

If you think my suggestion in [6] was not a good idea, you may be horrified to know that I also do the same thing on all my machines. No data has ever been eaten. Maybe they should rename libeatmydata to something more accurate?

In general, what one person thinks is not a good idea can become one in the right context. For example, my suggestion would not be out of place for a removable drive that holds no valuable data. I thought Arch Linux was about providing users with enough information to make good judgements, not taking it away. In keeping with the Pragmatism principle, I would kindly ask you to restore my edit, perhaps adding a warning as to the risks, but I will also understand if you choose not to. PBS (talk) 17:23, 12 November 2021 (UTC)

If fsync was really useless, it would not exist in the first place. Things that you don't use might depend on fsync. You also have no idea if other people put valuable data on their removable drive or not. Overall, I think your edit did not provide enough information to make good judgements. — Lahwaacz (talk) 17:32, 12 November 2021 (UTC)
You're absolutely right; could I edit it back with this information? (I disagree with your points about fsync, but this is NOT the place for that discussion.) PBS (talk) 18:42, 12 November 2021 (UTC)
Sure, it could be mentioned if it's objective. — Lahwaacz (talk) 22:01, 12 November 2021 (UTC)

Nvidia Secondary GPU Configs

Hi, regarding this change [[7]] I'm trying to make it easier to find a piece of info that I took significant time to find, can you point me to the config wiki and I'll add it there?

And Good Job, Arch Wiki has been a great companion and one of the reasons I love the distro.

—This unsigned comment is by Gabs12 (talk) 08:19, 13 November 2021. Please sign your posts with ~~~~!

Hi, the PRIME#Installation section describes what packages need to be installed for PRIME. Configuration is in the following sections on that page. For your use case it is probably PRIME#PRIME render offload, note that there is already a discussion about regarding the PrimaryGPU option. — Lahwaacz (talk) 10:44, 13 November 2021 (UTC)

Emphasizing that conflicts and provides are not the same thing

Hi again, Lahwaacz!

Four months ago you reverted an edit of mine; the reason you provided was that "it is obvious there is a difference" between conflicts and provides in a PKGBUILD. However I keep receiving messages/emails concerning packages I maintain in which people ask me to remove the conflicts variable when the provides variable is defined – the last email I received is from yesterday (concerning the notejot-gitAUR package) but you can also see FabioLolix' comments under cadet-gtkAUR – and every time I have to explain that conflicts and provides are not the same thing.

Basically, after reading that paragraph, people think that if provides is defined conflicts must not be defined. I think we should restore the text I had inserted (or a similar content). What do you think? --Grufo [ contribs | talk ] 11:42, 10 December 2021 (UTC)

I rewrote the old text, as it was actually not so good. If you have nothing against it, I will add this new draft to that paragraph:
Note that--Grufo when packages provide the same feature via the provides array, there is a difference between explicitly adding the alternative package to the conflicts array and not adding it. If the conflicts array is explicitly declared the two packages providing the same feature will be considered as alternative; if the conflicts array is missing the two packages providing the same feature will be considered as possibly cohabiting. Packagers should always ignore the content of the provides variable in deciding whether to declare a conflicts variable or not.
--Grufo [ contribs | talk ] 19:29, 12 December 2021 (UTC)
I made some further edits to your draft, but there is one more thing. It does not matter if the conflicts array is declared or missing, it might also contain an entry due to a different package. What matters is if it declares a conflict with the alternative package specified in provides. — Lahwaacz (talk) 19:00, 15 December 2021 (UTC)
Thank you, Lahwaacz. I will add it to the PKGBUILD article then. --Grufo [ contribs | talk ] 00:09, 16 December 2021 (UTC)

xorg

Hi Lahwaacz. You removed my edit "If you plan to start an Xorg session from the command line using startx(1) without a display manager, the xorg-xinit package will need to be installed." The xorg-xinit package (and, the startx script) is not included in either the xorg or xorg-apps groups. I believe this tip to explicitly install xinit should be mentioned in this section....before the Running Xorg section below it, to prevent unnecessary user frustration/forum resources. Misfit138 (talk) 15:46, 1 January 2022 (UTC)

Hi, I think the structuring is pretty clear and I don't see a point in cluttering the Xorg#Installation section even more, especially considering that all packages for running X are optional and their installation instructions are described on other pages. — Lahwaacz (talk) 18:51, 14 January 2022 (UTC)

Nextcloud

You have reverted my last edit of the Nextcloud article with the comment remove overly generic warning - add a specific link to a bug report if something is broken.

My motivation for inserting the warning block was a) a corresponding request on the discussion page and b) (more importantly) my own recent experience in this regard (see [8]).

I think you missed the point of this warning. It is important to make people aware of the possibility that system upgrades might break an existing Nextcloud installation. In this light it is vital to strongly advise to take precautions ahead of disaster, i.e. to apply some kind of snapshotting. As I wrote sometimes there is no (immediate) remedy for a problem (e.g. I was affected by the Failed opening required 'loud/index.php issue and there is no fix or workaround as of this writing). So just linking to some bug report (as you suggested) is no help at all for people with a broken Nextcloud installation.

So I kindly ask to re-revert, i.e. to insert my warning again.--Wolegis (talk) 07:47, 24 January 2022 (UTC)

System upgrades might break anything, that is not an excuse to add overly generic warnings like this. Furthermore, even your warning is no help at all for people with a broken Nextcloud installation. The wiki documents technical problems and solutions, thus the warning should be explicit and based on a bug report. — Lahwaacz (talk) 10:06, 24 January 2022 (UTC)

Creating pages for environment variables XDG_CURRENT_DESKTOP and DE

Hi, I am interested in creating pages for the DE related environment variables that are currently in Environment variables#Examples, such as XDG_CURRENT_DESKTOP and DE. These would be redirects to the page, except for DE, which would be a disambiguation page between the DE variable (currently Environment variables#Examples), and Desktop Environment. The purpose of this is to provide easier interlinking to these variables, and to facilitate providing more comprehensive documentation of how these variables affect different software. For instance, I intend on adding to the Qt page details on how its functionality varies depending on the DE (in addition to the styling differences).

I would like to hear your thoughts on this, particularly because you determined a DE page to conflict with the wiki style, in the past. Thanks, CodingKoopa (talk) 19:52, 15 March 2022 (UTC)

I'm sorry for getting so late to this. Looking at xdg-open, the DE variable seems like an internal variable that was never supposed to be set in the environment, so I'd just delete it altogether. As for the DE redirect/disambiguation, I would not like that in any case. But feel free to create a redirect for XDG_CURRENT_DESKTOP and other similarly standard variables. — Lahwaacz (talk) 16:59, 27 March 2022 (UTC)
Thank you for the response. Before I worked on the pages (see [9]), we only gave mention to DE, so I was somewhat under the impression that it has some significance outside of xdg-open. With that being said, I am struggling to locate any instances of it being read by any notable programs. Therefore, I will not pursue giving any more attention to this variable on the wiki, though I would like to keep the information on DE values in xdg-open because there are a significant amount of configurations and snippets out there (especially in older or uninformed Q&A posts) that reference it. If you would still like it to be deleted from the xdg-open and/or Environment variables, that can be entertained on those discussion pages. For here, though, this sufficiently answers my question, and I will proceed with creating XDG_CURRENT_DESKTOP and XDG_SESSION_DESKTOP. Closing. Thanks, CodingKoopa (talk) 18:18, 28 March 2022 (UTC)

SANE - See also - Ubuntu link

Hello, I'd like to revisit your recent deletion of a link [10] from SANE#See also. Besides their first section (Setting up SANE) and a couple outgoing links, it is otherwise a very good and succinct introduction of the SANE package & configuration. The information (e.g. Installing Network Scanners) is directly transferable to Arch. I found it especially useful while debugging my scanner issues, but felt it would be in poor taste to copy/paste sections of Ubuntu documentation into ArchWiki so I linked it instead. Isn't it acceptable to link relevant information, despite coming from another distro? By the way, thank you for the style & syntax corrections to my other edits - I try, but there's always something I miss. Regards, Thesqueakychair (talk) 15:22, 27 March 2022 (UTC)

In that case I think it would be more useful to link to a specific section(s) of their documentation from a relevant section of the sane page. — Lahwaacz (talk) 16:54, 27 March 2022 (UTC)
Good idea, I've made the change to SANE#Installation. Hopefully it's OK to stay this time. I'll strike this conversation and you can delete the whole section anytime if you choose. Thesqueakychair (talk) 20:52, 27 March 2022 (UTC)

Systemd-resolved

My issue is the inconsistency. Have a look at the mDNS section, where also a value gets supplied. Either you change the mDNS section as well, or you revert your revert and use my solution. --RubenKelevra (talk) 11:25, 19 April 2022 (UTC)

Your edit did not improve consistency, the mDNS section says "Otherwise, for NetworkManager, set mdns= in the [connection] section [...]" — Lahwaacz (talk) 06:03, 20 April 2022 (UTC)

xinit exec removal warning

It is inappropriate to scare users with an inappropriate warning such as the one you reverted. Please notice that I also removed the statement about removing the exec; without it, there is no need for the warning. If you really want to keep the warning, you definitely should rewrite it, since the current text is just pure FUD. The scenario described in it should never occur - a public kiosk with autologin enabled and exec removed for some reason. The exec removal suggestion already explicitly tells you that after X session ends, you return to the shell; there is no need to make any further warnings about it. There is no need for the exec removal suggestion in the first place - who would ever want this? Anybody who would, would already have to be an advanced user, who would not need to be told what exec does. So let's discuss how to get rid of the FUD here in a way you would accept.MikeSharov (talk) 13:53, 13 May 2022 (UTC)

If you say the warning should be rewritten, I'm sure you can provide a suggestion. So far you just tried to remove the content one way or the other... — Lahwaacz (talk) 14:24, 8 May 2022 (UTC)
I am not the one who said the warning should be rewritten; I said it should be removed, because the consequences of the change are already clearly stated by the statement explaining the change. I also said the suggestion itself should be removed because nobody should ever do this. It is normal to want to autostart xinit, but there is no point in continuing your session after X exits because if you are autostarting X, it is because you want to work in X. Anybody who would want to do otherwise is obviously not a novice, and anybody but a novice would already know both what exec does and what the consequences of removing it would be, obviating the need for both the suggestion and the warning. With the warning in place, novice users would be frightened into thinking that autostarting X would cause their account to be hacked, which is totally false. MikeSharov (talk) 13:53, 13 May 2022 (UTC)
Now the warning is gone. In the future I'd appreciate if you don't repeat your reverted edits just to reiterate your argument. — Lahwaacz (talk) 17:16, 14 May 2022 (UTC)
If I keep reiterating my argument it is because I am so frustrated at your inexplicably adamant desire to keep the inappropriate and useless exec removal suggestion. Without the warning it at least is not as confusing, so I am not inclined to continue the edit war, but why in the world do you keep putting it back in? You ignore my arguments like a brick wall and provide none of your own. Why clutter the wiki with this junk? MikeSharov (talk) 17:41, 14 May 2022 (UTC)

Pacman remove dangling packages command

Undo revision 732033 by Hanabishi (talk) - the command does not work as advertised (e.g. I have explicitly installed bemenu and the command tries to remove its dependency bemenu-wayland)

Hello. I think you are misusing something. I don't see any bmenu packages in the repository or AUR.

Anyway, the command

# pacman -Qqd | pacman -Rsu -

does not remove needed dependencies. It only can remove optional dependencies that is not explicitly installed, which is intended. Also you will be noticed about that, so this is ok. In fact it is just better version of pacman -Qttd described above in the article.

To test it efficiency install some circular package, e.g.:

# pacman -S --asdeps lib32-krb5

It will stuck in the system forever, pacman -Qttd does not detect it. But my command does.

—This unsigned comment is by Hanabishi (talk) 12:05, 9 June 2022. Please sign your posts with ~~~~!

Hi, then how do you explain this?
# pacman -S bemenu
resolving dependencies...
:: There are 3 providers available for bemenu-renderer:
:: Repository community
   1) bemenu-ncurses  2) bemenu-wayland  3) bemenu-x11

Enter a number (default=1): 2
looking for conflicting packages...
warning: dependency cycle detected:
warning: bemenu-wayland will be installed before its bemenu dependency

Package (3)               New Version  Net Change

community/bemenu-wayland  0.6.7-1        0.05 MiB
extra/wayland-protocols   1.25-1         0.45 MiB
community/bemenu          0.6.7-1        0.13 MiB

Total Installed Size:  0.63 MiB

:: Proceed with installation? [Y/n]
(3/3) checking keys in keyring                                                                                                                                                                   [------------------------------------------------------------------------------------------------------------------------] 100%
(3/3) checking package integrity                                                                                                                                                                 [------------------------------------------------------------------------------------------------------------------------] 100%
(3/3) loading package files                                                                                                                                                                      [------------------------------------------------------------------------------------------------------------------------] 100%
(3/3) checking for file conflicts                                                                                                                                                                [------------------------------------------------------------------------------------------------------------------------] 100%
(3/3) checking available disk space                                                                                                                                                              [------------------------------------------------------------------------------------------------------------------------] 100%
:: Processing package changes...
(1/3) installing wayland-protocols                                                                                                                                                               [------------------------------------------------------------------------------------------------------------------------] 100%
(2/3) installing bemenu-wayland                                                                                                                                                                  [------------------------------------------------------------------------------------------------------------------------] 100%
Note: bemenu's wayland backend only works
 in compositors which implement wlr-layer-shell.
(3/3) installing bemenu                                                                                                                                                                          [------------------------------------------------------------------------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
# pacman -S bemenu-x11
resolving dependencies...
looking for conflicting packages...

Package (1)           New Version  Net Change

community/bemenu-x11  0.6.7-1        0.03 MiB

Total Installed Size:  0.03 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                                                                                                                                   [------------------------------------------------------------------------------------------------------------------------] 100%
(1/1) checking package integrity                                                                                                                                                                 [------------------------------------------------------------------------------------------------------------------------] 100%
(1/1) loading package files                                                                                                                                                                      [------------------------------------------------------------------------------------------------------------------------] 100%
(1/1) checking for file conflicts                                                                                                                                                                [------------------------------------------------------------------------------------------------------------------------] 100%
(1/1) checking available disk space                                                                                                                                                              [------------------------------------------------------------------------------------------------------------------------] 100%
:: Processing package changes...
(1/1) installing bemenu-x11                                                                                                                                                                      [------------------------------------------------------------------------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
# pacman -Qqd | pacman -Rsu -
checking dependencies...
warning: removing readline from target list
...
[hundreds of other warnings follow!]
...

Package (3)        Old Version          Net Change

bemenu-wayland     0.6.7-1               -0.05 MiB
wayland-protocols  1.25-1                -0.45 MiB

Total Removed Size:  10.53 MiB

:: Do you want to remove these packages? [Y/n] n
The command also prints too many warnings which is not nice.
Lahwaacz (talk) 16:56, 9 June 2022 (UTC)
bemenu-wayland is not explicitly installed in this case. And as you have another dependency variant (bemenu-x11) installed, pacman decides that the dependency is fullfilled and you don't need both. Ask pacman devs why this works this way, not me.
In fact I think this is good and intentional behavior. There is only 1 package needed to fullfill the dependency. You always can do pacman -S bemenu-wayland to install it explicitly, if you want.
The command just does what it is intended to do: remove all dangling/unneeded packages. So the result is intentional.
Hanabishi (talk) 17:43, 9 June 2022 (UTC)
The pacman devs do not define what a "dangling package" means, you are combining two commands to achieve your goal. The fact that the packages are installed this way does not mean that the user would like them removed. This is similar to orphans and the difference between -Qt and -Qtt. The command suggested in the wiki should only detect the cycles between unneeded packages that would be inspected by the user and not suggest automatic removal. And of course, the suggested command should not print hundreds of unrelated warnings. — Lahwaacz (talk) 18:43, 9 June 2022 (UTC)
You are only concerned about its naming? Well, nevermind. I just wanted to share a useful command, which helps to remove unused remainings from the system better than -Qtt, not specifically for dependecy cycles, this was only 1 example case. Maybe it should have been called "remove all non-explicitly needed packages" or whatever.
Anyway, I don't want to argue further, sorry for wasting your time.
Hanabishi (talk) 19:50, 9 June 2022 (UTC)
Whatever you call it, it's hard to spot the difference from the existing section pacman/Tips and tricks#Removing unused packages (orphans) just from the section titles. But I'm more concerned with the suggested removal instead of just identification. — Lahwaacz (talk) 20:21, 9 June 2022 (UTC)
This can easily be altered by --print flag:
# pacman -Qqd | pacman -Rsu --print -
Which also hides the warnings btw.
Hanabishi (talk) 20:42, 9 June 2022 (UTC)
How about such variant: https://wiki.archlinux.org/index.php?title=Pacman%2FTips_and_tricks&type=revision&diff=733021&oldid=732625
Hanabishi (talk) 05:28, 17 June 2022 (UTC)
OK that looks good, thanks! — Lahwaacz (talk) 14:15, 17 June 2022 (UTC)