Difference between revisions of "User talk:Lahwaacz"

From ArchWiki
Jump to navigation Jump to search
(→‎Move templates: new section)
Line 355: Line 355:
:-- [[User:Amish|Amish]] ([[User talk:Amish|talk]]) 09:59, 10 December 2018 (UTC)
:-- [[User:Amish|Amish]] ([[User talk:Amish|talk]]) 09:59, 10 December 2018 (UTC)
== Move templates ==
Just because you disagree with my proposed renaming, I am not allowed to suggest it? Because that's what [[Template:Move]] claims to be for: 'to suggest renaming of an article.'
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 20:35, 23 December 2018 (UTC)

Revision as of 20:35, 23 December 2018

bot AUR to Official Repository edit

A recent bot edit (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 edit


{{AUR|gitolite}} is available in the [[Arch User Repository]]


{{Pkg|gitolite}} is available in the [[Arch User Repository]]

Tido.com (talk) 01:50, 1 April 2015 (UTC)

By "word distance" above what I _meant_ was 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 Distance package.

Example shamelessly ripped from that page:

(mainly because I couldn't link directly to the relevant section)

>>> sent1 = ['the', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog']
>>> sent2 = ['the', 'lazy', 'fox', 'jumps', 'over', 'the', 'crazy', 'dog']
>>> distance.levenshtein(sent1, sent2)

Tido.com (talk) 04:07, 1 April 2015 (UTC)

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 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 :)
-- Lahwaacz (talk) 17:51, 1 April 2015 (UTC)

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)


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)

PKGBUILD for AUR additional explanation

Where does it belong to then? Regards, -- wget (talk) 23:30, 23 January 2017 (UTC)

Here. -- 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. -- wget (talk) 23:37, 23 January 2017 (UTC)
Actually I had to 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. -- 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).

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.
-- 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.
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? -- 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? 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? -- 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. 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. MrHritik (talk) 20:22, 27 September 2017 (UTC)!

I'm pretty sure that the various backlight files in /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 Driver parameter was actually needed in the example - that might be a cleaner fix than the note? -- 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". MrHritik (talk) 20:22, 27 September 2017 (UTC)!
OK, reverted again. -- Lahwaacz (talk) 06:34, 29 September 2017 (UTC)


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>

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)

(Makepkg) Undo revision 504719

> "This will tell make to use all the cores." is exactly what plain -j$(nproc) does

No, -j tells make to use that many jobs, not cores. Please revert the revert, unless you are willing to insist that make has duplicated options. --Mpan (talk) 12:47, 29 December 2017 (UTC)

And -l tells make to not start more jobs if the current load is too high - that too is not directly related to "cores".
The -l and -j options are not duplicated. For example, I'd imagine that combining -j with the -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 -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.
-- 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, -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 -l option has been added for a reason, really. It’s not like GNU devs have nothing better to do than duplicating existing options. --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 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. -- Lahwaacz (talk) 21:58, 30 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,
[[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)

Bluetooth headset #Switch between HSV and A2DP setting

Hi Lahwaacz, 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. A clarification for the edit message would be nice.Chewtoy (talk) 16:17, 25 January 2018 (UTC)

I left the pacmd list-cards command on the page and removed only its output, see [3]. -- Lahwaacz (talk) 12:10, 27 January 2018 (UTC)
That I saw. But I'm wondering what the useless part is of saying what to look for when issuing the command.Chewtoy (talk) 12:17, 27 January 2018 (UTC)
It's pretty obvious from what the user sees that it's the index line, showing name: <bluez_card.23_5A_A3_A3_0E_1D> etc. in the example is just useless. -- Lahwaacz (talk) 12:26, 27 January 2018 (UTC)

Systemd-boot, EFI partition - how to keep older kernel modules loaded after update?

Hi Lahwaacz, you have left a summary "in that case the old versions of the relevant kernel modules will stay loaded so the mount will succeed" - but I could not understand in which "that" case, can you elaborate? F3flight (talk) 02:01, 26 May 2018 (UTC)

That case is with ESP mounted to /boot, which the removed text started with. -- Lahwaacz (talk) 08:14, 26 May 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)

Easy solution to select python version on CLI

Hi Lahwaacz,

You reverted my addition about a tool to select which python version to use on CLI. (Special:Diff/523929)

This was my first contribution so it might have been clumsy, or maybe I shouldn't have included my name in it.

Anyways, your motivation for reverting my change was this is not an ad board for hacks, there are enough methods described. I have a couple of points I'd like to discuss with you:

  • The page presents other hacks, that could considered dirtier than mine
  • I probably shouldn't have added my name, that could look like self promotion. I added it because I didn't want it to look like an official solution, but I really don't care if my name is included or not
  • Other methods are described, true, but I disagree that they are enough. I regularly run into issues with the methods described, that's why I built up another one, that is more clean and transparent and that works in many more cases than the methods already described.

So I feel that this "hack" can be useful to many others. As I said this was my first contribution so it probably needs to be re-phrased. Please advice :)

Pierre Killy (talk) 08:49, 26 June 2018 (UTC)

Not Lahwaacz but I agree with the revert.
  • The page only contains one dirty hack Dealing with version problem in build scripts, which should also be replaced.
  • Arch wiki articles generally do not link third party scripts. Code is either in packages or concise, embedded and explained in the article.
  • Running a shell script for every Python invocation is ridiculous.
--Larivact (talk) 11:02, 26 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)

Edits in Vim/YouCompleteMe

Hi! Did you accidentally delete word "here" or it's better practice to avoid this word in links? Link to diff. --Elnee (talk) 11:18, 28 November 2018 (UTC)

Hi, it was intentional, links with label such as "here" or "this" are discouraged (see Help:Style#Hypertext_metaphor). -- Lahwaacz (talk) 22:37, 28 November 2018 (UTC)
Thanks for reply. I will read that article. --Elnee (talk) 23:49, 28 November 2018 (UTC)

pg_ctl does not but /opt/pgsql-10/bin/pg_ctl does indeed create socket in /tmp by default

This is regarding you recent edit (undo of my edit)


I wish you had done the testing before editing.

You can verify yourself by following instructions given below.

Please run following:

First create temporary database which is compatible with old version 10

[root]# mkdir /var/lib/postgres/olddata
[root]# chown postgres:postgres /var/lib/postgres/olddata
[root]# su - postgres
[postgres]$ /opt/pgsql-10/bin/initdb /var/lib/postgres/olddata

Now that we have older version database, lets follow the upgradation procedure from Wiki.

[postgres]$ /opt/pgsql-10/bin/pg_ctl -D /var/lib/postgres/olddata start
2018-12-10 14:58:00.806 IST [24739] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"

Notice above the socket was created in /tmp

[postgres]$ pg_dumpall -f /tmp/old_backup.sql
pg_dumpall: could not connect to database "template1": could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/run/postgresql/.s.PGSQL.5432"?

Notice that pg_dumpall tried to connect to socket in /run/postgresql and failed.

[postgres]$ pg_dumpall -h /tmp -f /tmp/old_backup.sql

SUCCESS: hence pg_dumpall needs -h /tmp

If you agree then please UNDO your edit.

Thank you

PS: PostgreSQL recommends using newer version of pg_dumpall and not older. So we should not use /opt/pgsql-10/bin/pg_dumpall

-- Amish (talk) 09:59, 10 December 2018 (UTC)

Also see this patch which changes socket directory from /tmp to /run/postgresql.
So postgresql upstream - indeed uses /tmp but it is Arch that has added a patch.
However, this patch is "correctly" not applied to postgresql-old-upgrade so that newer version and older version dont use same socket and hence avoiding chance of corrupt database.
-- Amish (talk) 09:59, 10 December 2018 (UTC)

Move templates

Just because you disagree with my proposed renaming, I am not allowed to suggest it? Because that's what Template:Move claims to be for: 'to suggest renaming of an article.'

--Larivact (talk) 20:35, 23 December 2018 (UTC)