https://wiki.archlinux.org/api.php?action=feedcontributions&user=Everloop&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:43:45ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=583500User talk:Lahwaacz2019-09-21T08:14:36Z<p>Everloop: /* TSHARC touchscreen */ reply</p>
<hr />
<div><br />
== bot checking links after move ==<br />
<br />
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? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
: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 <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::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. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. 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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== aur-mirror ==<br />
<br />
Hi Lahwaacz,<br />
<br />
It seems that [http://pkgbuild.com/git/aur-mirror.git aur-mirror] has been down for a while.<br />
I'm not sure if this is intentional or not, but if it is, could you have Lahwaacz.bot remove [[Template:Aur-mirror]] from pages? At least where they are in a [[Template:Broken package link]] like {{ic|<nowiki>{{Broken package link|{{aur-mirror|foobar}}}}</nowiki>}}.<br />
<br />
If there is anything I can do to help, let me know.<br />
<br />
Thanks! [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 14:56, 19 October 2016 (UTC)<br />
<br />
:Maybe drifting a bit offtopic... but I'm in favor to finally remove any and all packages that are not on AUR4 from the wiki. Users have had over a year time to migrate, which is a century in Arch standards. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:21, 19 October 2016 (UTC)<br />
<br />
::I agree, especially on pages like [[List of games]] (already [https://wiki.archlinux.org/index.php?title=List_of_games&curid=4401&diff=454419&oldid=454356 took care of that]), and [[List of Applications]] (see [[Talk:List of applications#AUR3 packages]]). On other pages, where the non-existing packages are mentioned inline, it requires some more knowledge and effort to remove them. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:34, 19 October 2016 (UTC)<br />
<br />
:::Hmm... For the moment I just updated the template to point to Github instead. What would be the alternative "hint" without the link? It should still be different from just "package not found". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:08, 19 October 2016 (UTC)<br />
<br />
::::The GitHub repository is fine as well. I think we can keep that one while we (carefully) remove/update all broken links. Thanks! [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 06:52, 20 October 2016 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::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. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== GRUB/Tips and Tricks ==<br />
<br />
You reverted an edit I made to the /etc/grub.d/40_custom example at [[GRUB/Tips and tricks#Password_protection_of_GRUB_menu]], and your comment for doing so has me thinking you believe I put the heredoc syntax in to show someone how to cat mulitple lines from the command line. If that was my intent, I would agree with you that my change should be reverted. That's not what I was doing.<br />
<br />
The file contents as they are now produce an error upon running grub-mkconfig. I know because I tried this. The file ''contents'' need to include the heredoc syntax.<br />
<br />
In other words, if the file contents are the following, grub-mkconfig produces an error:<br />
set superusers="username"<br />
password_pbkdf2 username <password><br />
<br />
I was able to resolve this by adding the heredoc syntax, upon which everything worked. Again, the ''file contents'' need the heredoc syntax, as follows:<br />
cat << EOF<br />
set superusers="username"<br />
password_pbkdf2 username <password><br />
EOF<br />
<br />
With that in mind, I hope you'll agree that my edit was worthwhile.<br />
<br />
By the way, this isn't uncommon syntax for grub.d conf files. There are other examples of it, for instance section 3 of [https://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573 this AskUbuntu answer] for Mac users to activate their discrete video cards.<br />
<br />
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 12:13, 1 December 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
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 [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
: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: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
: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.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Page titles ==<br />
<br />
Hi, i need help. I didn't find answer on my question in archwiki. Is "Title (Language)/Sub-page (Language)" correct? It is logically. But in archwiki says only: <br />
"Also note that in case of sub-pages, the language tag still goes at the end, so "Title (Language)/Sub-page" is wrong, while "Title/Sub-page (Language)" is correct." -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 16:08, 21 January 2018 (UTC)<br />
<br />
:[[Help:I18n#Page titles]] is pretty clear on that "Title/Sub-page (Language)" is correct. It seems to me that "Title (Language)/Sub-page (Language)" would be superfluous.<br />
:The "(Language)" suffix applies to the entire "Title/Sub-page" bit as a whole. It can't be that the first (Language) is different from the second (Language), so why would you put it there twice?<br />
:-- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:48, 21 January 2018 (UTC)<br />
<br />
:Also see [[Help talk:Style#Slashes in titles]]. Seems like there was some discussion on this. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:58, 21 January 2018 (UTC)<br />
<br />
::If you use "Title/Sub-page (Language)", then you return to "Title", not to "Title (Language)". For examle, if you go to [[List of applications/Internet (Русский)]], and you want to go back through the "< List of applications", you will be taken to the English version of the page. -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 17:11, 21 January 2018 (UTC)<br />
<br />
::How about my variant? It is logically (for example, the ''Russian'' sub-page is part of ''Russian'' page. Schematically it look like this: {{ic|Title (Language)/Subpage (Language)}}). -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 18:00, 21 January 2018 (UTC)<br />
<br />
:::Hi, the {{ic|Title (Language)/Sub-page}} and {{ic|Title (Language)/Sub-page (Language)}} formats don't work, because the English page is {{ic|Title/Sub-page}} and the interlanguage links (shown in the left navigation column of each page) lead to {{ic|Title/Sub-page (Language)}}. Unfortunately, as I mentioned in [[Help_talk:Style#Localized_subpages]], there is no way to configure the interlanguage links to have the language in the middle of the page title. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:11, 21 January 2018 (UTC)<br />
<br />
::::We can do another format of Interlanguage links for sub-page. For examle,<br />
<nowiki>[[en:Title/Sub-page]]</nowiki><br />
<nowiki>[[es:Title (Español)/Sub-page]]</nowiki><br />
<nowiki>[[ru:Title (Русский)/Sub-page]]</nowiki><br />
::::See also [[CUPS (Русский)/Troubleshooting (Русский)]] and [[CUPS/Troubleshooting]]. Do i understand everything true? Must i fix this page? -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 05:00, 22 January 2018 (UTC)<br />
<br />
:::::Well, technically the {{ic|Title (Language)/Subpage (Language)}} format + {{ic|lang:Title (Language)/Subpage}} link would work, but repeating the language does not look nice (and I think there are even some pages like {{ic|Title/Subpage/Subsubpage}}). I think the ultimate goal is to use language namespaces as discussed in [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F]], but it's still a long way ahead so until then let's use what we have for consistency. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:08, 23 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* 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.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* 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?"<br />
* 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.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
: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).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::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? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::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. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::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. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== Archive (Español) ==<br />
<br />
Sorry for giving you some work today. I didn't know there should be only one "Archive" for all languages. You could have warned me and I would have corrected it for you. Best regards and sorry again. --[[User:AlonsoLP|AlonsoLP]] ([[User talk:AlonsoLP|talk]]) 11:38, 15 September 2018 (UTC)<br />
<br />
== Being in the vboxsf group does not automatically give you access to mount points ==<br />
<br />
Hi -<br />
<br />
Regarding revision #565457 of the VirtualBox Wiki page. I'm aware of what upstream says and hesitated before making this change, but I tested it myself (current non-dkms VirtualBox, fairly generic Arch client with the virtualbox-host-modules-arch package installed), and it just ''does not work''. Perhaps this is because automatic mounting is currently broken? (See https://bbs.archlinux.org/viewtopic.php?id=243871 which references a couple of bug reports.)<br />
<br />
In any case, on the Arch client, user pgoetz is in the vboxsf group. I set up a shared folder using the hypervisor GUI like this:<br />
<br />
:Folder Path: /home/pgoetz<br />
:Folder Name: pgoetz<br />
:Mount Point: /home/share/pgoetz<br />
<br />
:Read-only: no<br />
:Auto-mount: yes<br />
:Make Permanent: yes<br />
<br />
VBoxManage showvminfo {VM Name}<br />
<br />
shows the mount:<br />
<br />
:Shared folders:<br />
<br />
:Name: 'pgoetz', Host path: '/home/pgoetz' (machine mapping), writable, auto-mount, mount-point: '/home/share/pgoetz'<br />
<br />
but nothing is actually mounted there. Maybe this is the issue; if the folder were actually mounted there it would be write-accessible by any member of the vboxsf group<br />
<br />
However, the only way to get the mount to happen is to either mount it manually or create an entry in /etc/fstab.<br />
<br />
If I use this entry in /etc/fstab:<br />
<br />
pgoetz /home/share/pgoetz vboxsf rw,noauto,x-systemd.automount 0 0<br />
<br />
the folder is definitely '''not''' accessible by user pgoetz. In order to facilitate that, I have to use this /etc/fstab entry:<br />
<br />
pgoetz /home/share/pgoetz vboxsf uid=1000,gid=1000,rw,noauto,x-systemd.automount 0 0<br />
<br />
<br />
In any case, as stated currently on the VB Wiki page, it does not work, which is why I changed it, thinking that what is there will confuse people. We can leave it as is for now, and I'll test again if and when the hypervisor initiated automount starts working again.<br />
<br />
[[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 14:18, 2 February 2019 (UTC)<br />
<br />
:There are other places which mention the {{ic|vboxsf}} group (e.g. the previous section), so I found your edit more confusing than the original state. [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:27, 2 February 2019 (UTC)<br />
<br />
::Understood. I'll revisit this if and when the hypervisor automount works again. If it still doesn't work, I'll make sure I update it everywhere. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:00, 2 February 2019 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
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. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::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? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::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?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== Google error messages and [[GnuPG]] ==<br />
<br />
Hi, with regard to your removal of my edit of the Troubleshooting section of [[GnuPG]], I understand that it shouldn't just be TL;DR, but I'm wondering if there's a way to at least mention the error message, `sign_and_send_pubkey: signing failed: agent refused operation`, somewhere on the page, since I ran into that error with my smartcard (NitroKey) and googled the error message all across the web, before finally realizing the problem wasn't NitroKey-related at all, but [https://wiki.archlinux.org/index.php/GnuPG#Configure_pinentry_to_use_the_correct_TTY related to not pointing to the right TTY]. So I wanted to mention the error in some way on the page to enable others googling it to easier find what the problem is.<br />
<br />
Is there a smarter way to do that? --[[User:Madpet|Madpet]] ([[User talk:Madpet|talk]]) 11:31, 22 April 2019 (UTC)<br />
<br />
:You can't sensibly describe a catch-all error message for which there are at least a dozen of causes, most of them resulting from bad configuration. It should be clear that the whole configuration should be checked, no section is needed for that. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:47, 22 April 2019 (UTC)<br />
<br />
== wpa_supplicant ==<br />
<br />
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:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
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?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== <s>Regarding your edit in [[Silent boot#Retaining the vendor logo from BIOS]]</s> ==<br />
<br />
The vendor logo was already set by default to be retained and visible during bootup for me, but I wanted to manually configure it to disable the vendor logo. I searched wiki for instruction to turn it off, however it took me a few to find the correct section, even from googling the problem. My edit was to make it easier to be searched for, and to make it more clear that it was the section for disabling the vendor logo. It is quite possible that more people have it retained by default and want to disable it like I have.<br />
<br />
[[User:Jmarmstrong1207|Jmarmstrong1207]] ([[User talk:Jmarmstrong1207|talk]]) 17:15, 1 August 2019 (UTC)<br />
<br />
:Set by default where? The section already describes everything related, so maybe it should be just renamed to "Retaining or disabling the vendor logo from BIOS" to make it more discoverable. The subsection should be still "Disabling deferred takeover" though, because that's what it does. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:52, 1 August 2019 (UTC)<br />
<br />
My bad, it is set default as mentioned in the section, though some users may want it disabled. I agree that it should be renamed to that. [[User:Jmarmstrong1207|Jmarmstrong1207]] ([[User talk:Jmarmstrong1207|talk]]) 02:06, 11 August 2019 (UTC)<br />
<br />
:OK, thanks. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 11 August 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::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. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=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 {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::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. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== <s>Personal subpage links in the main articles</s> ==<br />
<br />
Ahoj, Jakub! There was a bit of the discussion about content of the [[Pacman (Русский)/Restore local database (Русский)]] article, but long story short, it ended with [[User:Xolst]] moving his way of the database backup/restore to [[User:Xolst/Restore local database 2.0 (Русский)|his own subpage]] and leaving link to it in the 'Related articles' section. So the question is, is it appropriate to have links in articles to personal subpages? I'm just curious as I don't recall such cases.<br />
<br />
Oh, and since I'm writing to you, there is an empty page [[InOut]] that I think can be deleted straight away.<br />
<br />
[[User:SlavMetal|SlavMetal]] ([[User talk:SlavMetal|talk]]) 21:46, 11 September 2019 (UTC)<br />
<br />
:Hi, user pages should not be linked from the main namespace, see [[Help:Style#User_pages]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:16, 14 September 2019 (UTC)<br />
<br />
::Oh, there it was, my bad. Thank you! -- [[User:SlavMetal|SlavMetal]] ([[User talk:SlavMetal|talk]]) 13:43, 15 September 2019 (UTC)<br />
<br />
== TSHARC touchscreen ==<br />
<br />
"Workaround if default touchscreen driver xf86-input-evdev + xinput_calibrator does not cover whole screen for touch."<br />
<br />
14:43, 14 September 2019 -> https://wiki.archlinux.org/index.php?title=Touchscreen&oldid=582312<br />
<br />
undo due: unacceptable format and not tested on Arch<br />
<br />
-> unacceptable format: my first wiki entry at archlinux.org - tried to be as close as possible to other entries on that page -> any hints how to format right?<br />
<br />
-> not tested on Arch: got a NCR SelfServ 60 (7409) running Kernel 5.2.11-1 MANJARO Linux (x86_64).<br />
<br />
"Manjaro - enjoy the simplicity<br />
https://manjaro.org<br />
Manjaro is an accessible, friendly, open-source Linux distribution and community. Based on Arch Linux [..]" -> Desktop Environment based on arch - headless or console does not make sense for touchscreens.<br />
<br />
[[User:Everloop|Everloop]] ([[User talk:Everloop|talk]]) 13:38, 17 September 2019 (UTC)<br />
<br />
:See [[Help:Style]] and related pages for proper formatting. However, "based on Arch Linux" is not the same as "'''is''' Arch Linux". They even have their own wiki: https://wiki.manjaro.org/index.php?title=Main_Page -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:44, 17 September 2019 (UTC)<br />
<br />
[[User:Everloop|Everloop]] ([[User talk:Everloop|talk]]) 08:14, 21 September 2019 (UTC)<br />
<br />
Ok, so i stick to Manjaro Wiki.</div>Everloophttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=582685User talk:Lahwaacz2019-09-17T13:38:25Z<p>Everloop: TSHARC touchscreen - undo due: unacceptable format and not tested on Arch</p>
<hr />
<div><br />
== bot checking links after move ==<br />
<br />
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? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
: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 <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::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. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. 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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== aur-mirror ==<br />
<br />
Hi Lahwaacz,<br />
<br />
It seems that [http://pkgbuild.com/git/aur-mirror.git aur-mirror] has been down for a while.<br />
I'm not sure if this is intentional or not, but if it is, could you have Lahwaacz.bot remove [[Template:Aur-mirror]] from pages? At least where they are in a [[Template:Broken package link]] like {{ic|<nowiki>{{Broken package link|{{aur-mirror|foobar}}}}</nowiki>}}.<br />
<br />
If there is anything I can do to help, let me know.<br />
<br />
Thanks! [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 14:56, 19 October 2016 (UTC)<br />
<br />
:Maybe drifting a bit offtopic... but I'm in favor to finally remove any and all packages that are not on AUR4 from the wiki. Users have had over a year time to migrate, which is a century in Arch standards. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:21, 19 October 2016 (UTC)<br />
<br />
::I agree, especially on pages like [[List of games]] (already [https://wiki.archlinux.org/index.php?title=List_of_games&curid=4401&diff=454419&oldid=454356 took care of that]), and [[List of Applications]] (see [[Talk:List of applications#AUR3 packages]]). On other pages, where the non-existing packages are mentioned inline, it requires some more knowledge and effort to remove them. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:34, 19 October 2016 (UTC)<br />
<br />
:::Hmm... For the moment I just updated the template to point to Github instead. What would be the alternative "hint" without the link? It should still be different from just "package not found". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:08, 19 October 2016 (UTC)<br />
<br />
::::The GitHub repository is fine as well. I think we can keep that one while we (carefully) remove/update all broken links. Thanks! [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 06:52, 20 October 2016 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::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. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== GRUB/Tips and Tricks ==<br />
<br />
You reverted an edit I made to the /etc/grub.d/40_custom example at [[GRUB/Tips and tricks#Password_protection_of_GRUB_menu]], and your comment for doing so has me thinking you believe I put the heredoc syntax in to show someone how to cat mulitple lines from the command line. If that was my intent, I would agree with you that my change should be reverted. That's not what I was doing.<br />
<br />
The file contents as they are now produce an error upon running grub-mkconfig. I know because I tried this. The file ''contents'' need to include the heredoc syntax.<br />
<br />
In other words, if the file contents are the following, grub-mkconfig produces an error:<br />
set superusers="username"<br />
password_pbkdf2 username <password><br />
<br />
I was able to resolve this by adding the heredoc syntax, upon which everything worked. Again, the ''file contents'' need the heredoc syntax, as follows:<br />
cat << EOF<br />
set superusers="username"<br />
password_pbkdf2 username <password><br />
EOF<br />
<br />
With that in mind, I hope you'll agree that my edit was worthwhile.<br />
<br />
By the way, this isn't uncommon syntax for grub.d conf files. There are other examples of it, for instance section 3 of [https://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573 this AskUbuntu answer] for Mac users to activate their discrete video cards.<br />
<br />
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 12:13, 1 December 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
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 [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
: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: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
: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.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Page titles ==<br />
<br />
Hi, i need help. I didn't find answer on my question in archwiki. Is "Title (Language)/Sub-page (Language)" correct? It is logically. But in archwiki says only: <br />
"Also note that in case of sub-pages, the language tag still goes at the end, so "Title (Language)/Sub-page" is wrong, while "Title/Sub-page (Language)" is correct." -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 16:08, 21 January 2018 (UTC)<br />
<br />
:[[Help:I18n#Page titles]] is pretty clear on that "Title/Sub-page (Language)" is correct. It seems to me that "Title (Language)/Sub-page (Language)" would be superfluous.<br />
:The "(Language)" suffix applies to the entire "Title/Sub-page" bit as a whole. It can't be that the first (Language) is different from the second (Language), so why would you put it there twice?<br />
:-- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:48, 21 January 2018 (UTC)<br />
<br />
:Also see [[Help talk:Style#Slashes in titles]]. Seems like there was some discussion on this. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:58, 21 January 2018 (UTC)<br />
<br />
::If you use "Title/Sub-page (Language)", then you return to "Title", not to "Title (Language)". For examle, if you go to [[List of applications/Internet (Русский)]], and you want to go back through the "< List of applications", you will be taken to the English version of the page. -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 17:11, 21 January 2018 (UTC)<br />
<br />
::How about my variant? It is logically (for example, the ''Russian'' sub-page is part of ''Russian'' page. Schematically it look like this: {{ic|Title (Language)/Subpage (Language)}}). -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 18:00, 21 January 2018 (UTC)<br />
<br />
:::Hi, the {{ic|Title (Language)/Sub-page}} and {{ic|Title (Language)/Sub-page (Language)}} formats don't work, because the English page is {{ic|Title/Sub-page}} and the interlanguage links (shown in the left navigation column of each page) lead to {{ic|Title/Sub-page (Language)}}. Unfortunately, as I mentioned in [[Help_talk:Style#Localized_subpages]], there is no way to configure the interlanguage links to have the language in the middle of the page title. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:11, 21 January 2018 (UTC)<br />
<br />
::::We can do another format of Interlanguage links for sub-page. For examle,<br />
<nowiki>[[en:Title/Sub-page]]</nowiki><br />
<nowiki>[[es:Title (Español)/Sub-page]]</nowiki><br />
<nowiki>[[ru:Title (Русский)/Sub-page]]</nowiki><br />
::::See also [[CUPS (Русский)/Troubleshooting (Русский)]] and [[CUPS/Troubleshooting]]. Do i understand everything true? Must i fix this page? -- [[User:ArchLinuxUser|ArchLinuxUser]] ([[User talk:ArchLinuxUser|talk]]) 05:00, 22 January 2018 (UTC)<br />
<br />
:::::Well, technically the {{ic|Title (Language)/Subpage (Language)}} format + {{ic|lang:Title (Language)/Subpage}} link would work, but repeating the language does not look nice (and I think there are even some pages like {{ic|Title/Subpage/Subsubpage}}). I think the ultimate goal is to use language namespaces as discussed in [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F]], but it's still a long way ahead so until then let's use what we have for consistency. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:08, 23 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* 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.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* 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?"<br />
* 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.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
: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).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::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? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::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. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::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. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== Archive (Español) ==<br />
<br />
Sorry for giving you some work today. I didn't know there should be only one "Archive" for all languages. You could have warned me and I would have corrected it for you. Best regards and sorry again. --[[User:AlonsoLP|AlonsoLP]] ([[User talk:AlonsoLP|talk]]) 11:38, 15 September 2018 (UTC)<br />
<br />
== Being in the vboxsf group does not automatically give you access to mount points ==<br />
<br />
Hi -<br />
<br />
Regarding revision #565457 of the VirtualBox Wiki page. I'm aware of what upstream says and hesitated before making this change, but I tested it myself (current non-dkms VirtualBox, fairly generic Arch client with the virtualbox-host-modules-arch package installed), and it just ''does not work''. Perhaps this is because automatic mounting is currently broken? (See https://bbs.archlinux.org/viewtopic.php?id=243871 which references a couple of bug reports.)<br />
<br />
In any case, on the Arch client, user pgoetz is in the vboxsf group. I set up a shared folder using the hypervisor GUI like this:<br />
<br />
:Folder Path: /home/pgoetz<br />
:Folder Name: pgoetz<br />
:Mount Point: /home/share/pgoetz<br />
<br />
:Read-only: no<br />
:Auto-mount: yes<br />
:Make Permanent: yes<br />
<br />
VBoxManage showvminfo {VM Name}<br />
<br />
shows the mount:<br />
<br />
:Shared folders:<br />
<br />
:Name: 'pgoetz', Host path: '/home/pgoetz' (machine mapping), writable, auto-mount, mount-point: '/home/share/pgoetz'<br />
<br />
but nothing is actually mounted there. Maybe this is the issue; if the folder were actually mounted there it would be write-accessible by any member of the vboxsf group<br />
<br />
However, the only way to get the mount to happen is to either mount it manually or create an entry in /etc/fstab.<br />
<br />
If I use this entry in /etc/fstab:<br />
<br />
pgoetz /home/share/pgoetz vboxsf rw,noauto,x-systemd.automount 0 0<br />
<br />
the folder is definitely '''not''' accessible by user pgoetz. In order to facilitate that, I have to use this /etc/fstab entry:<br />
<br />
pgoetz /home/share/pgoetz vboxsf uid=1000,gid=1000,rw,noauto,x-systemd.automount 0 0<br />
<br />
<br />
In any case, as stated currently on the VB Wiki page, it does not work, which is why I changed it, thinking that what is there will confuse people. We can leave it as is for now, and I'll test again if and when the hypervisor initiated automount starts working again.<br />
<br />
[[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 14:18, 2 February 2019 (UTC)<br />
<br />
:There are other places which mention the {{ic|vboxsf}} group (e.g. the previous section), so I found your edit more confusing than the original state. [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:27, 2 February 2019 (UTC)<br />
<br />
::Understood. I'll revisit this if and when the hypervisor automount works again. If it still doesn't work, I'll make sure I update it everywhere. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:00, 2 February 2019 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
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. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::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? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::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?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== Google error messages and [[GnuPG]] ==<br />
<br />
Hi, with regard to your removal of my edit of the Troubleshooting section of [[GnuPG]], I understand that it shouldn't just be TL;DR, but I'm wondering if there's a way to at least mention the error message, `sign_and_send_pubkey: signing failed: agent refused operation`, somewhere on the page, since I ran into that error with my smartcard (NitroKey) and googled the error message all across the web, before finally realizing the problem wasn't NitroKey-related at all, but [https://wiki.archlinux.org/index.php/GnuPG#Configure_pinentry_to_use_the_correct_TTY related to not pointing to the right TTY]. So I wanted to mention the error in some way on the page to enable others googling it to easier find what the problem is.<br />
<br />
Is there a smarter way to do that? --[[User:Madpet|Madpet]] ([[User talk:Madpet|talk]]) 11:31, 22 April 2019 (UTC)<br />
<br />
:You can't sensibly describe a catch-all error message for which there are at least a dozen of causes, most of them resulting from bad configuration. It should be clear that the whole configuration should be checked, no section is needed for that. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:47, 22 April 2019 (UTC)<br />
<br />
== wpa_supplicant ==<br />
<br />
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:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
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?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== <s>Regarding your edit in [[Silent boot#Retaining the vendor logo from BIOS]]</s> ==<br />
<br />
The vendor logo was already set by default to be retained and visible during bootup for me, but I wanted to manually configure it to disable the vendor logo. I searched wiki for instruction to turn it off, however it took me a few to find the correct section, even from googling the problem. My edit was to make it easier to be searched for, and to make it more clear that it was the section for disabling the vendor logo. It is quite possible that more people have it retained by default and want to disable it like I have.<br />
<br />
[[User:Jmarmstrong1207|Jmarmstrong1207]] ([[User talk:Jmarmstrong1207|talk]]) 17:15, 1 August 2019 (UTC)<br />
<br />
:Set by default where? The section already describes everything related, so maybe it should be just renamed to "Retaining or disabling the vendor logo from BIOS" to make it more discoverable. The subsection should be still "Disabling deferred takeover" though, because that's what it does. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:52, 1 August 2019 (UTC)<br />
<br />
My bad, it is set default as mentioned in the section, though some users may want it disabled. I agree that it should be renamed to that. [[User:Jmarmstrong1207|Jmarmstrong1207]] ([[User talk:Jmarmstrong1207|talk]]) 02:06, 11 August 2019 (UTC)<br />
<br />
:OK, thanks. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 11 August 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
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. <br />
<br />
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.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::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. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=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 {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::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. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== <s>Personal subpage links in the main articles</s> ==<br />
<br />
Ahoj, Jakub! There was a bit of the discussion about content of the [[Pacman (Русский)/Restore local database (Русский)]] article, but long story short, it ended with [[User:Xolst]] moving his way of the database backup/restore to [[User:Xolst/Restore local database 2.0 (Русский)|his own subpage]] and leaving link to it in the 'Related articles' section. So the question is, is it appropriate to have links in articles to personal subpages? I'm just curious as I don't recall such cases.<br />
<br />
Oh, and since I'm writing to you, there is an empty page [[InOut]] that I think can be deleted straight away.<br />
<br />
[[User:SlavMetal|SlavMetal]] ([[User talk:SlavMetal|talk]]) 21:46, 11 September 2019 (UTC)<br />
<br />
:Hi, user pages should not be linked from the main namespace, see [[Help:Style#User_pages]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:16, 14 September 2019 (UTC)<br />
<br />
::Oh, there it was, my bad. Thank you! -- [[User:SlavMetal|SlavMetal]] ([[User talk:SlavMetal|talk]]) 13:43, 15 September 2019 (UTC)<br />
<br />
== TSHARC touchscreen ==<br />
<br />
[[User:Everloop|Everloop]] ([[User talk:Everloop|talk]]) 13:38, 17 September 2019 (UTC)<br />
<br />
"Workaround if default touchscreen driver xf86-input-evdev + xinput_calibrator does not cover whole screen for touch."<br />
<br />
14:43, 14 September 2019 -> https://wiki.archlinux.org/index.php?title=Touchscreen&oldid=582312<br />
<br />
undo due: unacceptable format and not tested on Arch<br />
<br />
-> unacceptable format: my first wiki entry at archlinux.org - tried to be as close as possible to other entries on that page -> any hints how to format right?<br />
<br />
-> not tested on Arch: got a NCR SelfServ 60 (7409) running Kernel 5.2.11-1 MANJARO Linux (x86_64).<br />
<br />
"Manjaro - enjoy the simplicity<br />
https://manjaro.org<br />
Manjaro is an accessible, friendly, open-source Linux distribution and community. Based on Arch Linux [..]" -> Desktop Environment based on arch - headless or console does not make sense for touchscreens.</div>Everloophttps://wiki.archlinux.org/index.php?title=Touchscreen&diff=582312Touchscreen2019-09-14T14:43:10Z<p>Everloop: add TSHARC driver hint</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Displays]]<br />
[[ja:タッチスクリーン]]<br />
{{Merge|Calibrating Touchscreen}}<br />
<br />
{{Related articles start}}<br />
{{Related|Calibrating Touchscreen}}<br />
{{Related articles end}}<br />
<br />
If you ever tried to set up a touchscreen device in linux, you might have noticed that it's either working out of the box (besides some calibration) or is very tedious, especially when it is not supported by the kernel.<br />
<br />
== Introduction ==<br />
<br />
This article assumes that your touchscreen device is supported by the kernel (e.g. by the usbtouchscreen module). That means there exists a {{ic|/dev/input/event*}} node for your device. Check out<br />
<br />
less /proc/bus/input/devices<br />
<br />
to see if your device is listed or try<br />
<br />
cat /dev/input/event? # replace ? with the event numbers<br />
<br />
for every of your event nodes while touching the display. If you found the corresponding node, it's likely that you will be able to get the device working.<br />
<br />
== Available X11 drivers ==<br />
<br />
There are a lot of touchscreen input drivers for X11 out there. The most common ones are in the ''extra'' repository:<br />
<br />
* {{Pkg|xf86-input-evdev}} (likely the default driver if you plug in your touchscreen and it "just works")<br />
* {{Pkg|xf86-input-libinput}}; see also [[libinput]]<br />
* {{Pkg|xf86-input-elographics}}<br />
<br />
Less common drivers, not contained in the repository, are:<br />
<br />
* xf86-input-magictouch<br />
* xf86-input-mutouch<br />
* xf86-input-plpevtch<br />
* xf86-input-palmax<br />
<br />
Proprietary drivers exist for some devices (e.g.: {{AUR|xf86-input-egalax}}), but it's recommended to try the open source drivers first.<br />
<br />
Depending on your touchscreen device choose an appropriate driver. Again, evdev is likely to be the default if your touchscreen "just works."<br />
<br />
== evdev drivers ==<br />
<br />
=== Calibration ===<br />
<br />
Install {{AUR|xinput_calibrator}} (AUR). Then, run xinput_calibrator and follow the instructions. <br />
<br />
== Using a touchscreen in a multi-head setup ==<br />
To use multiple displays (some of which are touchscreens), you need to tell Xorg the mapping between the touch surface and the screen. This can be achieved with ''xinput'' as follows.<br />
<br />
Take for example the setup of having a wacom tablet and an external monitor; ''xrandr'' shows both displays: <br />
<br />
{{bc|<br />
$ xrandr<br />
Screen 0: minimum 320 x 200, current 2944 x 1080, maximum 8192 x 8192<br />
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm<br />
1024x768 60.0*+<br />
800x600 60.3 56.2 <br />
640x480 59.9 <br />
VGA1 connected 1920x1080+1024+0 (normal left inverted right x axis y axis) 477mm x 268mm<br />
1920x1080 60.0*+<br />
1600x1200 60.0 <br />
1680x1050 60.0 <br />
1680x945 60.0 <br />
}}<br />
<br />
You see we have two displays here. LVDS1 and VGA1. LVDS1 is the display internal to the tablet, and VGA1 is the external monitor. We wish to map our stylus input to LVDS1. So we have to find the ID of the stylus input:<br />
<br />
{{bc|<br />
$ xinput --list<br />
⎡ Virtual core pointer id&#61;2 [master pointer (3)]<br />
⎜ ↳ Virtual core XTEST pointer id&#61;4 [slave pointer (2)]<br />
⎜ ↳ QUANTA OpticalTouchScreen id&#61;9 [slave pointer (2)]<br />
⎜ ↳ TPPS/2 IBM TrackPoint id&#61;11 [slave pointer (2)]<br />
⎜ ↳ Serial Wacom Tablet WACf004 stylus id&#61;13 [slave pointer (2)]<br />
⎜ ↳ Serial Wacom Tablet WACf004 eraser id&#61;14 [slave pointer (2)]<br />
⎣ Virtual core keyboard id&#61;3 [master keyboard (2)]<br />
↳ Virtual core XTEST keyboard id&#61;5 [slave keyboard (3)]<br />
↳ Power Button id&#61;6 [slave keyboard (3)]<br />
↳ Video Bus id&#61;7 [slave keyboard (3)]<br />
↳ Sleep Button id&#61;8 [slave keyboard (3)]<br />
↳ AT Translated Set 2 keyboard id&#61;10 [slave keyboard (3)]<br />
↳ ThinkPad Extra Buttons id&#61;12 [slave keyboard (3)]<br />
}}<br />
<br />
We see that we have two stylus inputs. We now need to simply map our inputs to our output like so:<br />
<br />
xinput --map-to-output 'Serial Wacom Tablet WACf004 stylus' LVDS1<br />
xinput --map-to-output 'Serial Wacom Tablet WACf004 eraser' LVDS1<br />
<br />
You can automate this by putting these commands in your {{ic|~/.xinitrc}} or similar. The mapping will be lost if the touchscreen is disconnected and re-connected, for example, when switching monitors via a KVM. In that case it is better to use a udev rule. The [[Calibrating Touchscreen]] page has an example udev rule for the case when a transformation matrix has been calculated manually and needs to be applied automatically. <br />
{{expansion|How to automate the map-to-output operation above?}}<br />
<br />
== Touchegg ==<br />
<br />
[[Touchegg]] is a multitouch gesture program, that runs as a user in the background, recognizes gestures, and translates them to more conventional events such as mouse wheel movements, so that you can for example use two fingers to scroll. But it also interferes with applications or window managers which already do their own gesture recognition. If you have both a touchpad and a touchscreen, and if the touchpad driver (such as synaptics or libinput) has been configured not to recognize gestures itself, but to pass through the multi-touch events, then Touchegg will recognize gestures on both: this cannot be configured. In fact it does a better job of recognizing gestures than either the synaptics or libinput touchpad drivers; but on the touchscreen, it's generally better for applications to respond to touch in their own unique ways. Some Qt and GTK applications do that, but they will not be able to if you have Touchegg "eating" the touch events. So, Touchegg is useful when you are running mainly legacy applications which do not make their own use of touch events.<br />
<br />
== Firefox ==<br />
<br />
See [[Firefox/Tweaks#Enable touchscreen gestures]].<br />
<br />
== TSHARC ==<br />
<br />
Workaround if default touchscreen driver xf86-input-evdev + xinput_calibrator does not cover whole screen for touch.<br />
<br />
Tested on Linux 5.2.11-1 MANJARO (x86_64).<br />
<br />
TSHARC Linux Driver 3.04c (3.23 install is more bugged):<br />
<br />
https://www.microchip.com/design-centers/tsharc/software-drivers-and-driver-manuals<br />
<br />
Install:<br />
<br />
sudo sh ./Tsharc304c/install.sh<br />
Enter selection: 1<br />
Enter selection: 12<br />
<br />
"TSHARC" device number:<br />
<br />
sudo pacman -S xorg-xinput<br />
xinput > "TSHARC" > [device number]<br />
<br />
Disable X11 touch screen and start tsharc deamon:<br />
<br />
xinput disable [device number]<br />
boot.tsharc start<br />
<br />
Setting up "TSHARC", see readme.txt for details.<br />
<br />
hlincal<br />
<br />
Disable X11 touchscreen and start tsharc deamon at boot<br />
<br />
sudo cp /Tsharc304c/xinitrcheader /etc/X11/xinit/xinitrc.d/99-xinitrcheader.sh<br />
sudo nano /etc/X11/xinit/xinitrc.d/99-xinitrcheader.sh<br />
add: "xinput disable [device number]" after "#!/bin/sh"<br />
sudo chmod +x /etc/X11/xinit/xinitrc.d/99-xinitrcheader.sh</div>Everloop