Difference between revisions of "User talk:Lahwaacz"

From ArchWiki
Jump to navigation Jump to search
m (Add comment)
 
(203 intermediate revisions by 30 users not shown)
Line 1: Line 1:
== bot AUR to Official Repository edit ==
 
 
A recent bot edit ([https://github.com/lahwaacz/wiki-scripts/blob/master/update-package-templates.py update Pkg/AUR templates]) by [[User:Lahwaacz.bot]] on the [[Gitolite]] page correctly changed the AUR template to Pkg but left the [[Arch User Repository]] link
 
 
I fixed this, but would it be possible to modify the bot to take this into consideration?
 
 
I can imagine that blanket changing AUR links to Official Repository links in any given page could be dangerous - but for common phrasing or possibly word distance it would seem to be relatively safe
 
 
Or is there some sort of post-run manual inspection that I am unaware of that handles this situation?
 
 
Specifically this [https://wiki.archlinux.org/index.php?title=Gitolite&diff=next&oldid=366859 edit]
 
 
From:
 
<pre>
 
{{AUR|gitolite}} is available in the [[Arch User Repository]]
 
</pre>
 
 
To:
 
<pre>
 
{{Pkg|gitolite}} is available in the [[Arch User Repository]]
 
</pre>
 
 
 
 
[[User:Tido.com|Tido.com]] ([[User talk:Tido.com|talk]]) 01:50, 1 April 2015 (UTC)
 
 
By "word distance" above what I _meant_ was [[Wikipedia:Edit Distance|Edit Distance]] ;)
 
 
I was initially thinking of Hamming distance - but apparently that is for strings of equal length.
 
 
What looks more promising is the Levenshtein distance - specifically "Comparing a list of strings" from the Python [https://pypi.python.org/pypi/Distance/0.1.3 Distance] package.
 
 
Example shamelessly ripped from that page:
 
 
(mainly because I couldn't link directly to the relevant section)
 
 
<pre>
 
>>> sent1 = ['the', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog']
 
>>> sent2 = ['the', 'lazy', 'fox', 'jumps', 'over', 'the', 'crazy', 'dog']
 
>>> distance.levenshtein(sent1, sent2)
 
3
 
</pre>
 
[[User:Tido.com|Tido.com]] ([[User talk:Tido.com|talk]]) 04:07, 1 April 2015 (UTC)
 
 
:Hi,
 
:the bot currently does not touch the surrounding text at all, it only modifies the package templates or appends [[Template:Broken package link]] when the package is not found. This is obviously not perfect, this behaviour may lead to some incorrect combinations as you noticed, but blindly fixing the package links and not the surrounding text is still considered to be an improvement. Checking the surrounding text manually would require a lot of manpower, which we don't have, so it is currently not done systematically. Feel free to ask for further details or see the most recent discussion: [[ArchWiki:Requests#Strategy_for_updating_package_templates]].
 
:Regarding automatic updates of the surrounding text, the edit distance gives a clue about whether given edit should be performed or not, but it does not define how an edit should be performed. It can be useful in cases where there are multiple feasible substitutions in text and the strategy to select the optimal substitution is e.g. to minimize the Levenshtein distance. But we don't have any algorithm to generate feasible substitutions yet, so this technique fails. The surrounding text substitution is also very context sensitive and wiki bots must be designed in a way to minimize (ideally avoid completely) the [[wikipedia:Error_of_the_first_kind|error of the first kind]], which in this case is modifying correct text to be incorrect. This makes defining general rules for the text substitution really hard, on the other hand many rules would be necessary to cover even the basic form of standard wording, so in the end both ways may be comparably hard. Anyway, if you have some ideas, I'm all ears :)
 
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:51, 1 April 2015 (UTC)
 
  
 
== bot checking links after move  ==
 
== bot checking links after move  ==
Line 74: Line 26:
  
 
::::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)
 
::::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)
 
== PKGBUILD for AUR additional explanation ==
 
 
[https://wiki.archlinux.org/index.php?title=Arch_User_Repository&type=revision&diff=466474&oldid=466429 Where does it belong to then]? Regards, -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:30, 23 January 2017 (UTC)
 
 
:[[PKGBUILD#Package_relations|Here]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 23:35, 23 January 2017 (UTC)
 
 
::Ok. I was actually hesitating between that page and the one I had actually written to. I'll repost to the right location then. Thanks for letting me know. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 23:37, 23 January 2017 (UTC)
 
 
:::Actually I had to [https://wiki.archlinux.org/index.php?title=PKGBUILD&diff=486527&oldid=486509 remove it] again. I think it would be better if you proposed the example in a talk page, I have no idea what was the point given the "Even this is not recommended..." sentence. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:31, 23 August 2017 (UTC)
 
 
== Reversion of pip autoconversion tools. ==
 
 
Can you discuss why you reverted https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=491150 ?
 
 
Obviously, as the author of PyPI2PKGBUILD, I may not be completely neutral on this topic.  However:
 
 
As mentioned in https://wiki.archlinux.org/index.php/Python#Package_management, "it is always preferred to use pacman to install software" (which I definitely agree with).  However, some important Python packages have been outdated for a long time on the Arch repositories (a major example being IPython, which has been flagged five months ago and is quite widely used); moreover, many "smaller" Python packages have rather poor quality, hand-written PKGBUILDs on the AUR (https://aur.archlinux.org/packages/python-jupyter_kernel_test/ is an example of a PKGBUILD which can mispackage if the user has a ~/.config/pip/pip.conf set).  Thus, for packages that are not available on the official repos (or severely outdated there), I consider it better to autogenerate the PKGBUILD rather than having the AUR flooded with low-quality PKGBUILDs.
 
 
Note that I specifically suggested that such autogenerated PKGBUILDs should be for personal use (I would consider uploading them to the AUR to be in complete contradiction of the philosophy explained above).
 
 
[[User:Anntzer|Anntzer]] ([[User talk:Anntzer|talk]]) 09:05, 24 September 2017 (UTC)
 
 
:The [[Python package guidelines]] page is about ''writing'' PKGBUILDs manually, not about generating them. I doubt that the "for personal use" clause would prevent people from sharing the generated PKGBUILDs...
 
:I don't see how outdated or poorly written PKGBUILDs are relevant here.
 
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:17, 24 September 2017 (UTC)
 
 
::I can replace "for personal use" by a more explicit "Do not upload such PKGBUILDs to the AUR" if you prefer...
 
::Outdated PKGBUILDs are relevant because one of the main selling points of Arch is exactly the ability to keep everything up to date.  When a package as important as IPython is not updated for five months, this selling point simply does not apply anymore.  Obviously it is easy for each user to fetch the IPython PKGBUILD, edit it manually and build a package for a more recent version, but it seems clear that doing this in an automatic fashion is preferable.
 
::Bad quality PKGBUILDs are relevant because they are just... highly annoying?  I don't see why anyone would be happy with bad PKGBUILDs floating around the AUR (I know it is the responsibility of each user to check PKGBUILDs from the AUR, but certainly it is better to decrease the background noise?).  Moreover, *even* if all packages on the AUR were of high quality, they would simply duplicate the information available on PyPI, but with an unnecessary delay.  In fact, IMO, most PyPI packages should be autogenerated rather than obtained either from the Arch repos or from the AUR; the only exceptions being those that require a lengthy compilation step (and in that case the AUR does not really help), have non-detectable non-Python dependencies, or have incorrect metadata on PyPI that prevents their correct autopackaging.
 
::[[User:Anntzer|Anntzer]] ([[User talk:Anntzer|talk]]) 11:02, 24 September 2017 (UTC)
 
 
:::So automatic generation is very important ''to you''. Now, how is it relevant for the description of packaging guidelines, i.e. the standards that even the generators should conform to? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 24 September 2017 (UTC)
 
 
::::Should we not all strive to improve the quality and up-to-date-ness of packages that Arch users can install?  I do not consider this to be a solely personal issue; I also consider that in the vast majority of the cases, an autogenerated PKGBUILD is of better quality than most hand-written ones.  In a sense, I would consider the autogenerated PKGBUILD to be the lowest bar for a PKGBUILD -- if you cannot write a better one then don't bother writing it yourself.  And in case you are wondering, PyPI2PKGBUILD does follow the guidelines (I would consider anything else a bug) -- in fact I contributed some of them!...
 
 
::::If you consider that autogeneration tools are out of scope for this page, would you also strike out go-makepkg from the [[Go package guidelines]], cblrepo from the [[Haskell package guidelines]], and pacgem and gem2arch from the [[Ruby Gem package guidelines]]? [[User:Anntzer|Anntzer]] ([[User talk:Anntzer|talk]]) 11:42, 24 September 2017 (UTC)
 
 
:::::Yes, I didn't like them either so I moved them to [[Creating_packages#PKGBUILD_generators]]. Do you like it enough? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:17, 24 September 2017 (UTC)
 
 
::::::I would actually have written "Autogenerated PKGBUILDs should not be submitted to the AUR" (regardless of their quality), but heh. [[User:Anntzer|Anntzer]] ([[User talk:Anntzer|talk]]) 19:09, 24 September 2017 (UTC)
 
 
== About installation of "xf86-video-intel" package. ==
 
 
I did not have xf86-video-intel package installed yet I had intel_backlight. [[User:MrHritik|MrHritik]] ([[User talk:MrHritik|talk]]) 20:22, 27 September 2017 (UTC)!
 
 
:I'm pretty sure that the various backlight files in {{ic|/sys}} are managed by the kernel, and are not dependent on which drivers you install, so that makes sense. I was wondering, however, whether the {{ic|Driver}} parameter was actually needed in the example - that might be a cleaner fix than the note? -- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 19:06, 27 September 2017 (UTC)
 
 
::I can confirm that removing xf86-video-intel and the line "Driver intel" generates the error "No outputs have backlight property".  [[User:MrHritik|MrHritik]] ([[User talk:MrHritik|talk]]) 20:22, 27 September 2017 (UTC)!
 
 
:::OK, reverted again. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:34, 29 September 2017 (UTC)
 
  
 
== mkosi ==
 
== mkosi ==
Line 155: Line 56:
  
 
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 12:13, 1 December 2017 (UTC)
 
[[User:Djmoch|Djmoch]] ([[User talk:Djmoch|talk]]) 12:13, 1 December 2017 (UTC)
 
== (Makepkg) Undo revision 504719 ==
 
 
> "This will tell {{ic|make}} to use all the cores." is exactly what plain -j$(nproc) does
 
 
 
No, {{ic|-j}} tells {{ic|make}} to use that many jobs, not cores. Please revert the revert, unless you are willing to insist that {{ic|make}} has duplicated options. --[[User:Mpan|Mpan]] ([[User talk:Mpan|talk]]) 12:47, 29 December 2017 (UTC)
 
 
:And {{ic|-l}} tells make to not start more jobs if the current load is too high - that too is not directly related to "cores".
 
:The {{ic|-l}} and {{ic|-j}} options are not duplicated. For example, I'd imagine that combining {{ic|-j}} with the {{ic|-l}} flag would be useful to limit the resources for some background process (such as automatic builds on a buildbot) if the CPU is occupied with other tasks. Your edit did not explain why {{ic|-j$(nproc)}} is not enough - obviously in some cases more jobs than cores may be needed, but my argument is that in common cases one job can fully utilize one core (at least for the vast majority if the job's duration), so the section does not have to deal with the less common options. There is a link to the man page anyway.
 
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:06, 29 December 2017 (UTC)
 
 
:: It works both ways. The core may underutilized, as you have pointed out; but also may also be overloaded. While this is not common for build tools to be multithreaded, {{ic|-j 7}} may as well have load of 10, which is not the intention of a person who set it to 7 to have 12.5% of their 8-core platform free.
 
:: The {{ic|-l}} option has been added for a reason, really. It’s not like GNU devs have nothing better to do than duplicating existing options. --[[User:Mpan|Mpan]] ([[User talk:Mpan|talk]]) 21:27, 30 December 2017 (UTC)
 
 
:::Then the person who wants to have 12.5% of their platform free would have to disregard your sentence "This will tell {{ic|make}} to use all the cores." anyway. If some other build system runs multiple make instances at the same time, it's not really a problem of make to deal with the consequent problem - the "outer" build system should be configured instead. Again, that's out of the scope of that generic section. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:58, 30 December 2017 (UTC)
 
  
 
== Waking from suspend with USB device ==
 
== Waking from suspend with USB device ==
Line 223: Line 108:
 
:::::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)
 
:::::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)
  
== Bluetooth headset #Switch between HSV and A2DP setting ==
+
== Are supported local/remote destinations important for choosing a backup program? ==
 +
 
 +
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:
 +
* 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.
 +
 
 +
[[User:Jernst|Jernst]] ([[User talk: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).--[[User:Larivact|Larivact]] ([[User talk: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? {{Unsigned|18:08, 12 June 2018‎|Jernst}}
 +
 
 +
:::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)
 +
 
 +
::::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)
 +
 
 +
== Archive (Español) ==
 +
 
 +
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)
 +
 
 +
== Being in the vboxsf group does not automatically give you access to mount points ==
 +
 
 +
Hi -
 +
 
 +
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.)
 +
 
 +
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:
 +
 
 +
:Folder Path: /home/pgoetz
 +
:Folder Name: pgoetz
 +
:Mount Point: /home/share/pgoetz
 +
 
 +
:Read-only: no
 +
:Auto-mount: yes
 +
:Make Permanent: yes
 +
 
 +
VBoxManage showvminfo {VM Name}
 +
 
 +
shows the mount:
  
Hi Lahwaacz,
+
:Shared folders:
I'm trying to understand how the instructions for for how to find the card number is usless (see your edit https://wiki.archlinux.org/index.php?title=Bluetooth_headset&oldid=508422 )
+
 
I myself had trouble finding the information before on the page and added it for clarity for those of us who had never dealt with these controls to begin with.
+
:Name: 'pgoetz', Host path: '/home/pgoetz' (machine mapping), writable, auto-mount, mount-point: '/home/share/pgoetz'
A clarification for the edit message would be nice.[[User:Chewtoy|Chewtoy]] ([[User talk:Chewtoy|talk]]) 16:17, 25 January 2018 (UTC)
+
 
 +
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
 +
 
 +
However, the only way to get the mount to happen is to either mount it manually or create an entry in /etc/fstab.
 +
 
 +
If I use this entry in /etc/fstab:
 +
 
 +
  pgoetz  /home/share/pgoetz  vboxsf  rw,noauto,x-systemd.automount  0  0
 +
 
 +
the folder is definitely '''not''' accessible by user pgoetz.  In order to facilitate that, I have to use this /etc/fstab entry:
 +
 
 +
  pgoetz  /home/share/pgoetz  vboxsf  uid=1000,gid=1000,rw,noauto,x-systemd.automount  0  0
 +
 
 +
 
 +
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.
 +
 
 +
[[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 14:18, 2 February 2019 (UTC)
 +
 
 +
: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)
 +
 
 +
::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)
 +
 
 +
== 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. – [[User:Flying sheep|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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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? – [[User:Flying_sheep|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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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?]] – [[User:Flying_sheep|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?
 +
 
 +
--
 +
 
 +
[[User:Pooryorick|Pooryorick]] ([[User talk: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.
 +
 
 +
[[User:Eurydice|Eurydice]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)
 +
 
 +
:::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)
 +
 
 +
::::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)
 +
 
 +
== RStudio HiDPI ==
 +
 
 +
I do not understand your reasoning for this [https://wiki.archlinux.org/index.php?title=HiDPI&diff=586566&oldid=586565 revert]: "nothing here is specific to rstudio". Are you suggesting the bit about GUI toolkits should be removed (or moved to the top of the [[HiDPI#Applications]] section)? I included this because RStudio's behaviour (as a Qt application) differs depending on user's environment. Regardless, why remove the explicit example for launching a scaled RStudio instance too? [[User:Gmcd|Gmcd]] ([[User talk:Gmcd|talk]]) 22:30, 18 October 2019 (UTC)
 +
 
 +
:The behaviour of any Qt application is already covered in [[HiDPI#Qt 5]]. Explaining how to use specific values for different applications does not belong to the [[HiDPI]] page, it is covered in [[Environment variables]] and [[Desktop entries#Modify environment variables]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:44, 19 October 2019 (UTC)
 +
 
 +
== Sway#Backlight_toggle ==
 +
 
 +
Hi, The instructions in the section before my edit were right (sorry for the misleading comment message) but I thought it could be more detailed (and so I edited), Insert as hotkey is a bad choice for sure, but why not just change it to Pause? did you not like the way that I modified for some reason? Why choose ''/bin/dash'' over ''/usr/bin/sh'' in a script that maybe the person reading doesn't have ''dash'' (I know it may be changed)? And sorry for this bunch of questions. [[User:Jyeno|Jyeno]] ([[User talk:Jyeno|talk]]) 15:31, 7 November 2019 (UTC)
 +
 
 +
:Sorry for the delay, I've used different edit summaries the second time: [https://wiki.archlinux.org/index.php?title=Sway&diff=588939&oldid=588792], [https://wiki.archlinux.org/index.php?title=Sway&diff=588940&oldid=588939]. I hope that's alright with you... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:02, 15 November 2019 (UTC)
 +
 
 +
== .desktop env ==
 +
 
 +
the example clearly shows {{ic|~/.local/share/applications/}}
 +
 
 +
mind using the talk page instead of revert with a long explanation next time, thx --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 14:35, 12 December 2019 (UTC)
 +
 
 +
:The current wording is also [https://wiki.archlinux.org/index.php?title=Desktop_entries&type=revision&diff=583026&oldid=580395 recent] so I could have just linked that edit instead of explaining the reason. Anyway, if you want to discuss, let's start :-)  [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:20, 12 December 2019 (UTC)
 +
 
 +
::well, I sort of already did. I see no reason for the complex personal examples for something so simple --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 20:40, 12 December 2019 (UTC)
 +
 
 +
:::I'm not convinced, people usually have a reason to add a note to the wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:05, 14 December 2019 (UTC)
  
:I left the {{ic|pacmd list-cards}} command on the page and removed only its output, see [https://wiki.archlinux.org/index.php?title=Bluetooth_headset&type=revision&diff=508422&oldid=508416]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:10, 27 January 2018 (UTC)
+
::::you usually remove things to keep it simple, and why aren't you convinced? how more plain can {{ic|~/.local/share/applications/}} be? --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 10:41, 14 December 2019 (UTC)
  
::That I saw. But I'm wondering what the useless part is of saying what to look for when issuing the command.[[User:Chewtoy|Chewtoy]] ([[User talk:Chewtoy|talk]]) 12:17, 27 January 2018 (UTC)
+
:::::The point of concise (meaning succinct, not just brief) articles is not in the amount of text or examples, but in how easily it can be read and understood. In this case, the section title is "Modify environment variables" and ~/.local/share/applications/ does not contain anything, so your version did not include all important information - it was brief, but not concise. The current version is longer, but not too long. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:20, 14 December 2019 (UTC)
  
:::It's pretty obvious from what the user sees that it's the index line, showing {{ic|name: <bluez_card.23_5A_A3_A3_0E_1D>}} etc. in the example is just useless. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:26, 27 January 2018 (UTC)
+
::::::what do you think about the sed part, imo it's like a wall in your face. --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:25, 16 December 2019 (UTC)
  
==<s> Transclusion </s>==
+
:::::::It's short enough and self-contained in the Tip template, so didn't mind it. But after second thought, I've [https://wiki.archlinux.org/index.php?title=Desktop_entries&diff=593563&oldid=591495 removed it]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:07, 30 December 2019 (UTC)
  
''[Moved to [[Help talk:Style#Transclusion]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:37, 15 April 2018 (UTC)]''
+
== dracut executable link ==
  
== <s>Awaiting response to #How to archive templates</s> ==
+
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.
  
[[ArchWiki_talk:Administrators#How_to_archive_templates|#How to archive templates]] stalled just a bit over 2 years ago, if you would give your response to [[User:Kynikos|Kynikos]] I would appreciate it. I can give my feedback whenever appropriate, just that yours was asked first and I don't want to hijack the discussion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:15, 12 May 2018 (UTC)
+
{{unsigned|17:06, 28 January 2020‎|Krathalan}}
  
:Let's just say that I'm undecided, so feel free to go on with your feedback. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:58, 13 May 2018 (UTC)
+
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)
  
::I'm cool with this, see you there later :) -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:07, 20 May 2018 (UTC)
+
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)

Latest revision as of 19:51, 28 January 2020

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)

aur-mirror

Hi Lahwaacz,

It seems that aur-mirror has been down for a while. 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 {{Broken package link|{{aur-mirror|foobar}}}}.

If there is anything I can do to help, let me know.

Thanks! Lonaowna (talk) 14:56, 19 October 2016 (UTC)

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. -- Alad (talk) 16:21, 19 October 2016 (UTC)
I agree, especially on pages like List of games (already 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. -- Lonaowna (talk) 16:34, 19 October 2016 (UTC)
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". -- Lahwaacz (talk) 18:08, 19 October 2016 (UTC)
The GitHub repository is fine as well. I think we can keep that one while we (carefully) remove/update all broken links. Thanks! Lonaowna (talk) 06:52, 20 October 2016 (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)

GRUB/Tips and Tricks

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.

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.

In other words, if the file contents are the following, grub-mkconfig produces an error:

set superusers="username"
password_pbkdf2 username <password>

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:

cat << EOF
set superusers="username"
password_pbkdf2 username <password>
EOF

With that in mind, I hope you'll agree that my edit was worthwhile.

By the way, this isn't uncommon syntax for grub.d conf files. There are other examples of it, for instance section 3 of this AskUbuntu answer for Mac users to activate their discrete video cards.

Djmoch (talk) 12:13, 1 December 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)

Page titles

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: "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." -- ArchLinuxUser (talk) 16:08, 21 January 2018 (UTC)

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.
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?
-- Lonaowna (talk) 16:48, 21 January 2018 (UTC)
Also see Help talk:Style#Slashes in titles. Seems like there was some discussion on this. -- Lonaowna (talk) 16:58, 21 January 2018 (UTC)
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. -- ArchLinuxUser (talk) 17:11, 21 January 2018 (UTC)
How about my variant? It is logically (for example, the Russian sub-page is part of Russian page. Schematically it look like this: Title (Language)/Subpage (Language)). -- ArchLinuxUser (talk) 18:00, 21 January 2018 (UTC)
Hi, the Title (Language)/Sub-page and Title (Language)/Sub-page (Language) formats don't work, because the English page is Title/Sub-page and the interlanguage links (shown in the left navigation column of each page) lead to 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. -- Lahwaacz (talk) 21:11, 21 January 2018 (UTC)
We can do another format of Interlanguage links for sub-page. For examle,
[[en:Title/Sub-page]]
[[es:Title (Español)/Sub-page]]
[[ru:Title (Русский)/Sub-page]]
See also CUPS (Русский)/Troubleshooting (Русский) and CUPS/Troubleshooting. Do i understand everything true? Must i fix this page? -- ArchLinuxUser (talk) 05:00, 22 January 2018 (UTC)
Well, technically the Title (Language)/Subpage (Language) format + lang:Title (Language)/Subpage link would work, but repeating the language does not look nice (and I think there are even some pages like 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. -- Lahwaacz (talk) 22:08, 23 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)

Archive (Español)

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. --AlonsoLP (talk) 11:38, 15 September 2018 (UTC)

Being in the vboxsf group does not automatically give you access to mount points

Hi -

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.)

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:

Folder Path: /home/pgoetz
Folder Name: pgoetz
Mount Point: /home/share/pgoetz
Read-only: no
Auto-mount: yes
Make Permanent: yes
VBoxManage showvminfo {VM Name}

shows the mount:

Shared folders:
Name: 'pgoetz', Host path: '/home/pgoetz' (machine mapping), writable, auto-mount, mount-point: '/home/share/pgoetz'

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

However, the only way to get the mount to happen is to either mount it manually or create an entry in /etc/fstab.

If I use this entry in /etc/fstab:

 pgoetz  /home/share/pgoetz  vboxsf  rw,noauto,x-systemd.automount  0  0

the folder is definitely not accessible by user pgoetz. In order to facilitate that, I have to use this /etc/fstab entry:

 pgoetz  /home/share/pgoetz  vboxsf  uid=1000,gid=1000,rw,noauto,x-systemd.automount  0  0


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.

Pgoetz (talk) 14:18, 2 February 2019 (UTC)

There are other places which mention the vboxsf group (e.g. the previous section), so I found your edit more confusing than the original state. Lahwaacz (talk) 15:27, 2 February 2019 (UTC)
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. Pgoetz (talk) 16:00, 2 February 2019 (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)

RStudio HiDPI

I do not understand your reasoning for this revert: "nothing here is specific to rstudio". Are you suggesting the bit about GUI toolkits should be removed (or moved to the top of the HiDPI#Applications section)? I included this because RStudio's behaviour (as a Qt application) differs depending on user's environment. Regardless, why remove the explicit example for launching a scaled RStudio instance too? Gmcd (talk) 22:30, 18 October 2019 (UTC)

The behaviour of any Qt application is already covered in HiDPI#Qt 5. Explaining how to use specific values for different applications does not belong to the HiDPI page, it is covered in Environment variables and Desktop entries#Modify environment variables. -- Lahwaacz (talk) 09:44, 19 October 2019 (UTC)

Sway#Backlight_toggle

Hi, The instructions in the section before my edit were right (sorry for the misleading comment message) but I thought it could be more detailed (and so I edited), Insert as hotkey is a bad choice for sure, but why not just change it to Pause? did you not like the way that I modified for some reason? Why choose /bin/dash over /usr/bin/sh in a script that maybe the person reading doesn't have dash (I know it may be changed)? And sorry for this bunch of questions. Jyeno (talk) 15:31, 7 November 2019 (UTC)

Sorry for the delay, I've used different edit summaries the second time: [3], [4]. I hope that's alright with you... -- Lahwaacz (talk) 19:02, 15 November 2019 (UTC)

.desktop env

the example clearly shows ~/.local/share/applications/

mind using the talk page instead of revert with a long explanation next time, thx --Ubone (talk) 14:35, 12 December 2019 (UTC)

The current wording is also recent so I could have just linked that edit instead of explaining the reason. Anyway, if you want to discuss, let's start :-) Lahwaacz (talk) 15:20, 12 December 2019 (UTC)
well, I sort of already did. I see no reason for the complex personal examples for something so simple --Ubone (talk) 20:40, 12 December 2019 (UTC)
I'm not convinced, people usually have a reason to add a note to the wiki. -- Lahwaacz (talk) 10:05, 14 December 2019 (UTC)
you usually remove things to keep it simple, and why aren't you convinced? how more plain can ~/.local/share/applications/ be? --Ubone (talk) 10:41, 14 December 2019 (UTC)
The point of concise (meaning succinct, not just brief) articles is not in the amount of text or examples, but in how easily it can be read and understood. In this case, the section title is "Modify environment variables" and ~/.local/share/applications/ does not contain anything, so your version did not include all important information - it was brief, but not concise. The current version is longer, but not too long. -- Lahwaacz (talk) 12:20, 14 December 2019 (UTC)
what do you think about the sed part, imo it's like a wall in your face. --Ubone (talk) 09:25, 16 December 2019 (UTC)
It's short enough and self-contained in the Tip template, so didn't mind it. But after second thought, I've removed it. -- Lahwaacz (talk) 12:07, 30 December 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)