Jump to content
ArchWiki

ArchWiki talk:Requests

From ArchWiki
(Redirected from Requests)
Latest comment: 19:58 by Indigo in topic Creation requests
Notice for editors Questionable edits should be reported directly on the page itself via an appropriate article status template, or on the respective talk page.

Is the wiki missing documentation for a popular software package or coverage of an important topic? Or, is existing content in need of correction, updating, or expansion? Write your requests below and share your ideas...

Creation requests

Latest comment: 19:58 15 comments8 people in discussion
Notice for editors Here, list requests for topics that you think should be covered on ArchWiki. If not obvious, explain why ArchWiki coverage is justified (rather than existing Wikipedia articles or other documentation). Furthermore, please consider researching and creating the initial article yourself (see Help:Editing for content creation help).

Mirror troubleshooting

Unfortunately, Mirrors#Troubleshooting is a bit lacking and can definitely benefit from more information such as how to detect a bad mirror. A mirror becoming faulty is not extremely uncommon so this topic should definitely be covered, including who to tell about the bad mirror so it can e.g be removed from the mirrorlist.

This topic is impacting enough people that it is worth putting it into here.

-- NetSysFire (talk) 00:07, 6 August 2021 (UTC) Reply

The bad mirror case i covered now. Should another section, about a mirror returning 404, be added or information in is Pacman#Packages_cannot_be_retrieved_on_installation enough? --Mpan (talk) 08:19, 6 August 2021 (UTC) Reply
Thanks for contributing! The content you added looks good. Some information helping how to determine that a mirror is faulty is still missing. The section you mentioned is unfortunately not containing enough information on that and would be specific to the Mirrors article anyways. If any developer or other person knowing mirror internals sees this, please share your knowledge in debugging mirrors.
-- NetSysFire (talk) 17:19, 6 August 2021 (UTC) Reply
fixed --Matthewq337 (talk) 01:35, 25 January 2026 (UTC) Reply
As far as I see from other Matthewq337 edits, he places "fixed" quite randomly. So, is it fixed indeed? — Andrei Korshikov (talk) 18:16, 28 January 2026 (UTC) Reply

Contain Flatpak application troubleshooting to a subpage

As suggested in Talk:Steam#Remove/move flatpak instructions, we should create a Flatpak/Application-specific troubleshooting to have a central place for people using Arch that also choose non-native packages.

--Erus Iluvatar (talk) 11:23, 2 February 2026 (UTC) Reply

I don't say no, but... what about just using Flatpak#Troubleshooting? Flatpak isn't very long page, is the subpage needed indeed?
Of course, as a reader I prefer subpages, but as an editor I hate them:) So... it's just another clarification question:)
— Andrei Korshikov (talk) 14:12, 6 February 2026 (UTC) Reply
IMO the Troubleshooting section is for troubleshooting with either Flatpak itself or issues common with all (or a major chunk of) Flatpak applications, while the proposed page would be more like what we already have for Steam/Game-specific troubleshooting, CUPS/Printer-specific problems, etc...
I'm curious as why you hate sub-pages as an editor though?
-- Erus Iluvatar (talk) 19:01, 6 February 2026 (UTC) Reply
Aha, I see. That's another kind of troubleshooting:) Now I understand and agree.

I'm curious as why you hate sub-pages as an editor though?

Oops... After a night of sleep I agree that I've chosen strange wording:)
The only use-case I hate as an editor is a troubleshooting subpage which was splitted from the parent page, because such splitting breaks the history. Of course, some kind of wiki blame helps, but that's another story:)
I.e., to be clear, of course I like subpages in general (because I like structural approach and all that stuff), but when I see "/Troubleshooting"... I definitely feel blue:) — Andrei Korshikov (talk) 09:10, 7 February 2026 (UTC) Reply
Ah yes, reminds me of the first time I wanted to see the early history of the Beginners' guide :D
-- Erus Iluvatar (talk) 09:33, 7 February 2026 (UTC) Reply

Category for Texinfo article

I want to write an article about creating info pages using Texinfo, the document description language used by the info system.

I am wandering about what category or subcategory, I should choose. From looking at the existing categories so far, no one seem to be particularly suitable for a markup language, like Texinfo.

Should I create a new category "Markup languages", "Typesetting languages" or "Documentation systems", or stick with something else?

I have already written an article for Texinfo on Medium, and I am planning to edit it a bit for ArchWiki, but this should give you an idea of what the future Texinfo article will look like: Writing an Info page in Linux

P.S.: In the future, I am open to creating an article about writing man pages, which the uses groff, a typesetting language, so a new category or at least a new subcategory could prove really useful. MartinMihalkov (talk) 09:11, 30 June 2026 (UTC) Reply

These articles seem to be off-topic on ArchWiki. Apart from a few exceptions (e.g. systemd), articles should primarily contain Arch-specific information. — andreymal (talk) 15:26, 30 June 2026 (UTC) Reply
Welcome to the ArchWiki @MartinMihalkov. A related, pretty comprehensive article we have is man page, which links to GNU#Texinfo for now. Any category should encompass both at least, but fixing a category is secondary/done later. It's more important to focus on the toolchain we have in repositories and its configuration to get going. As another example, I'd like to refer git to you. In it you see what Andreymal refers to, i.e. we link out basic usage skills to external projects and focus on Arch specifics. You can perhaps have a look at both for TOC (table of content) ideas you consider a relevant Texinfo structure for this wiki.
--Indigo (talk) 19:17, 30 June 2026 (UTC) Reply
Thank you for the fast response, --Indigo! Would it be okay, if I only leave the details for how to convert a texinfo source file to an output format and how to import info pages in the Info system? MartinMihalkov (talk) 08:07, 1 July 2026 (UTC) Reply
I've seen you have been busy on a draft along that. Sure, it reads interesting to me, but I also reckon target audience for these topics are more developers/ documenters than users. IMHO your article should start with a section covering brief usage (reading, basic navigation; a new user-focused info info). You bringing up Texinfo made me realise we don't describe it adequately anywhere (again, see the structure of man page), hence it would be useful to have it improve our brief GNU#Texinfo coverage so far. While info coreutils probably is the showcase for Texinfo, new users may be unaware they can use info systemd to navigate the systemd manual pages interactively. See it like the article having nodes (subsections) relevant to crosslink from other wiki articles (e.g. applications/libraries which provide additional info documentation/tutorials). Makes sense? These are just my thoughts, maybe others chime in. --Indigo (talk) 19:58, 2 July 2026 (UTC) Reply

Modification requests

Latest comment: 23 April 35 comments15 people in discussion
Notice for editors Here, list requests for correction or other modification of existing articles. Only systemic modifications that affect multiple articles should be included here. If a specific page needs modification, use that page's discussion or talk page instead and one of the article status templates.

As a rolling release, Arch is constantly receiving updates and improvements. Because of this the Arch wiki must be updated quickly to reflect these changes.

Creating packages from other distributions

Could we have a section, in the Arch package guidelines perhaps, that discusses how to create a PKGBUILD for binary packages (such as from .deb files)?

--Stickynotememo (talk) 04:04, 1 April 2026 (UTC) Reply

(a) Arch package guidelines is definitely a wrong place: it's about packaging from source for the Arch official repositories.
(b) @Stickynotememo, what do you miss (i.e. what unanswered questions do you have)? PKGBUILD for .deb just extracts files from an archive, that's all (see, for example, my https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cvs-feature-bin).
I want to close this topic as "not a question". — Andrei Korshikov (talk) 18:29, 13 April 2026 (UTC) Reply
(a) From what I've seen APG covers both AUR and official packages; both come under the banner of 'Arch Packages', since they use PKGBUILDs and makepkg.
(b) I understand these explanations exist elsewhere on the internet but that could probably be said about many pages on the Archwiki. It would still be nice to have an explanation. Stuff you could put on there might be: where to get debian packages from, unarchiving steps, etc. Your decision, though Stickynotememo (talk) 11:03, 20 April 2026 (UTC) Reply
(a)

From what I've seen APG covers both AUR and official packages

Could you explain? Esp. "From what I've seen" — where have you seen that?
Of course, AUR packages usually follow guidelines for official packages, but it is more etiquette thing, not a hard rule.
(b)

where to get debian packages from, unarchiving steps, etc.

Aha, I see. We have Creating packages for other distributions, and you request for something like Creating packages/From other distributions. I will reopen and rename this topic. — Andrei Korshikov (talk) 17:07, 20 April 2026 (UTC) Reply
No, the question was basically about repackaging .deb files as Arch Linux packages rather than making Arch packages on other distros.
About Arch package guidelines: that page aims to cover rules for all Arch packages, but especially the official ones. Specific cases and scenarios not concerning official packages are out of scope. Also things that are possible are not necessarily the same as the things that should be done. There is a strong consensus that Arch packages should be built from source and while binary packages are not forbidden in the AUR, we don't see the need to formalize guidelines for this case.
Lahwaacz (talk) 13:13, 21 April 2026 (UTC) Reply

the question was basically about repackaging .deb files as Arch Linux packages

I tried to say that in general form the question is about repackaging .deb / .rpm / whatever else as Arch Linux packages. I see that "Creating packages/From other distributions" looks misleading. Repackaging or Creating packages/Repackaging should be better names:)
— Andrei Korshikov (talk) 06:59, 23 April 2026 (UTC) Reply

Change drive naming/accessing to UUID?

Trying to install drives with/out Luks, LVM on internal, external drives is quite complicated currently. Following the ralated articles suggest different ways of reaching the goal. Many different drive name conventions are suggested, eg.:

  • /dev/sda2
  • /dev/md0
  • /dev/mapper/md/0
  • /dev/mapper/vgroup-lvm-root
  • /dev/vgroup-luks/root
  • ...

Some of them don't work with portable external drives. This overcomplicates setting up encrypted drives in different situations. My suggestion is, to change all drive related articles to one specific solution of addressing drives universal. Currently I think of UUDI drive naming as a way to go. This would ease the process of drive naming in all kinds of situations:

  • The reader is guided through system setup along one red line
  • Troubleshootiing "no drie found" is strait forward
  • Many sections become clearer to read even when not reading the whole article
  • Articles are easier to write and maintain
  • Beginners have an easier read and geta better idea of how to access drives
  • Accessing internal/external encrypted drives is easy

' LMV or other virtual file systems are easier to describe and setup

Ok, I know it is a big suggestion. I wanted to bring it up here, bacause I have the impression that following one primary path would help a lot - everyone involved. It doesn't need to be done in one day. While I think to have one suggested guideline would be a good start. Then with thain mind, we all have it easier to change those sections while Writing/editing Wiki entries.

T.ask (talk) 11:22, 30 March 2015 (UTC) Reply

Hi, To your own examples above: using an UUID for a /dev/mapper/* device declaration is generally unnecessary (the uniqueness of the device is determined when it is mapped). I think you overestimate the amount of users who actually require setting up the examples where it really matters (e.g. external drives). What I don't understand is why you consider using UUIDs being easier to read/describe. For starters the terribly long UUIDs will break formatting in many cases, e.g. making code blocks in-text not possible. An UUID itself gives no contextual hint, something that a device name does. If you look at the three examples in Persistent block device naming#Boot managers, you really find the UUID one the easiest?
I think you are certainly right in that we may lack crosslinks to Persistent_block_device_naming in some articles where it may be important to use an UUID. Maybe we also need an example section to illustrate singular important points in Persistent block device naming and maybe there are individual articles/sections where content should indeed use a form of persistent naming straight away.
Suggestion: How about using Talk:Persistent block device naming to assemble a list of particular article sections with content where persistent naming should be made more prominent? That way we could also figure if and which examples may be useful to be added. --Indigo (talk) 17:47, 30 March 2015 (UTC) Reply
Hi, I started this topic because "by design" Linux has so many ways to assign drives and the Wiki uses them kind of "randomly". Finding the best drive naming method for the Wiki is my intention. Giving the reader a hand, by enabling him/her to understand one way of accessing drives and collect all the others somewhere.
I'm suggesting UUIDs, because they can be used for local and mobile situations. They are easy to use. The UUID format is universal and is independent of the location (local/mobile) or the context (LVM, Raid, Luks, ...) in which they are used.
The reason why I'm bring this up is, that it seems, the wiki has currently no standardized form of drive path declaration. If we can find one practical method, it will be easier to write, edit and maintain articles. Everyone involved will know then, which method is the recommended.
Therefore, I wanted to start an open conversation, to find ideas to improve the situation. I guess, UUIDs are also a good choice, because they are easy to substitute with pseudo code, eg.:
  • "mount /dev/disks/by-uuid/e9ea05ce-0ccb-87a1-c71e-90fab8be1944 /mnt"
could then be written as:
  • "/dev/disks/by-uuid/[UUID] /mnt"
instead of having the choice of:
  • "mount /dev/sda3 or
  • /dev/mapper/vgroup--lvm-root or
  • /dev/md/0 or
  • /dev/md0 or
  • ... /mnt"
The reader immediately knows:
  • "I just need to alter [UUID]"
There is no need to know of all possible alternative methods making use of the Wiki example. Because the user already learned (Beginners Guide) how to determine UUIDs those examples are well adoptable.
Reduced uncertainties like the reader had before:
  • Can I use that example's local path in my case, too?
  • What's my case anyway? And how is it different for the one provided?
  • Is my drive IDE, SATA or ... what?
  • Where and how is the correct format of my drive/partitions's path?
  • I need an example to boot my USB drive everywhere. That provided example doesn't work for me. Where is the article I need to know?
  • I skimmed through many articles, no success so far. There must be one, but where?
  • I have an Luks, Raid, LVM (or mixed) situation here. The current article just uses /dev/sdi3. What to do?
  • Which article do I need to read first? I can't use the current example. How about alternatives?
The reader's issue is, that "/dev/sdb3" drive paths aren't that descriptive without the knowledge of how and when they are used as written. They are nice for that particular situation, but may immediately loose their meaning in other use cases?!
If we could pick out one drive naming method the Wiki uses, then we are able to eliminate many of the upper soliloquies and ...
  • We get a good article structure for the writer, reader and maintainer.
  • The provided method will work in either situation (local/mobile/..).
  • All alternative methods can be listed in one conversion article/table.
The reader can quickly move on reading the article:
  • Great, I already know how to determine UUIDs. I just change it..
As you mentioned, crosslinks then point to one subpage, where the conversion to other alternative methods is explained.
Don't get me wrong, I don't want to imply something is wrong with the current way the Wiki does it. This just a natural process how something grows. A bit of standardization may help here.
I'm for UUIDs so far, because are easily exchangeable and can be written as [UUID] in the Wiki.
OMG, I wrote a huge wall of text. Sorry for that. It's not easy and very time consuming writing down what I wanted to say. as a non-native speaker. I hope, it's now easier to understand what my intention was. I'm kind of uncertain that I found the right words. --T.ask (talk) 13:24, 31 March 2015 (UTC) Reply
Thank you for elaborating on the background of why you propose it. No need to apologize at all for taking the time to give input how to improve our wiki! I just want to add two thoughts on it:
(1) One reason descriptive device declarations (/dev/sda/...) are easy to grasp is that everyone is used to them. It starts when you open any partitioning tool - you start it for a device from the /dev tree. Try to find the term "UUID" in the manpage of cfdisk/cgdisk/parted (fdisk has it, the others not a mention). With this I don't want to say your intention to introduce the user early to use persistent naming is wrong, just that using descriptive naming is common and, thereby, accessible to the reader.
(2) I like your idea of using a "/dev/disks/by-uuid/[(削除) YOUR (削除ここまで)UUID] /mnt" format (we call other instances of such 'pseudo-variables'). Still, if you used it in an article context, e.g. an encrypted LVM, you would still have to more verbosely describe which dev/blockdevice/vg/lv UUID is meant to be mounted on /mnt. I still can't really picture for myself how writing and reading it is easier in general.
As I wrote above, I agree we might need to pinpoint the advantages of persistent naming more, but we do some already (e.g. right from the start: Beginners' guide#Generate an fstab). In short I believe we are better off with the way we have it (no rule on it, as long as the contribution fits the article contributed to all editors may choose what's best in context). That's it from me. Looking forward to read feedback & other opinions. --Indigo (talk) 20:46, 31 March 2015 (UTC) Reply
IMO man page examples are sometimes a bit behind "new standards". That's natural and this shouldn't prevent us from moving a bit more forward. With Arch we have UUIDs - lets use them :)
In case the user doesn't know UUIDs, we will guide him/her to a short conversion-table/article on how to switch to UUIDs. Actually it's much easier to grasp than often thought:
  • Just enter lsblk -f and it's obvious which UUID points to which drive in any context (raid, luks, lvm, ...). As this Get UUID example shows, just copy the corresponding UUID and use it with all UUID Wiki examples. IMHO it's quite easy.
I see where you are coming from, while I'm confident the reader will learn fast how UUIDs work. A new user will not even know which other options have been there before. Moreover, as the reader is already familiar with UUIDs he/she won't experience future problems with moving drives around. The experienced user just reads the conversion-table/article.
You see, I'm quite confident that the user will grasp UUIDs easily. Also, this will prevent him/her from experiencing future problems. We just need the courage to do the first step. It's not something we need to do in one day. We have all the time to slowly move into one direction.
That's why I would also appreciate other opinions on this topic here.
T.ask (talk) 12:45, 1 April 2015 (UTC) Reply
Hi, T.ask, thank you for discussing this, however I'm not sure if this is all only theoretical or you have a precise idea of how to put it into practice, because after reading all the discussion I haven't understood very well how this idea would change our articles. At this stage you must choose one of our important articles, e.g. LVM, and explain us how the article would change in details, so we can discuss on something more tangible. — Kynikos (talk) 14:37, 2 April 2015 (UTC) Reply
Hi, Kynikos. Yes, it's always better to have a good practical example if things seem to be complicated. I'm quite busy right now. When I find the time, I will start changing the Wiki (slowly) as I mentioned before. LVM is a nice example, while I would like to start with those sections which are easier to adapt and more commonly used. Especially if I need to add a new subsection (How do you work with UUIDs) beforehand. --T.ask (talk) 10:44, 21 April 2015 (UTC) Reply
As I said, it would be better if you showed us an example here or in your User page before starting to actually "chang[e] the Wiki". Take your time of course :) — Kynikos (talk) 02:30, 22 April 2015 (UTC) Reply

php-fpm

In preparation to making all (php) webapps use a dedicated user, I extended information on PostfixAdmin and realized, that the information on php-fpm is scattered all over the articles of nginx and apache (and probably all over some other web server pages as well). I think the citation/ linking in all of the web server pages and the php web application pages would greatly improve, if this information was moved to a dedicated page, or to a sub-page for PHP, as it is quite PHP specific (unlike e.g. uwsgi). Davezerave (talk) 00:55, 26 May 2019 (UTC) Reply

Information about older kernels/ program versions

Is there guidance on how long information about kernel and program versions should be kept ? e.g "btrfs supports this as of linux 5.0" or "fdisk supports GPT since...." It's mildly interesting when those are recent changes but a lot of occurrences on the wiki relate to versions which have been removed from repos for years... I think in most cases it adds unnecessary clutter, ideas ?

-- Cvlc (talk) 12:39, 23 January 2023 (UTC) Reply

There is an old stalled discussion at Help talk:Style#"as of version X.XX..." on this subject. --Erus Iluvatar (talk) 13:30, 23 January 2023 (UTC) Reply
I think "how long" is the key. If no one (roughly) uses the previous versions, then they can be removed. We can use Pkgstats to observe the usage. İsmail Arılık (talk) 07:31, 25 November 2025 (UTC) Reply

Localize the sidebar texts

I don't know if I should post it under here, but here it is.

Since many of the languages' ArchWiki just directly sit on English ArchWiki, having sidebar being half-translated would be a bit weird.

so, on MediaWiki:Sidebar, each second level item represents a link (texts on the left of | is the destination and on the right of it is the "name". I'll call these "name"s as "message"s below, you'll know the reason), and some of the first level item represents a title. When displaying the sidebar, MediaWiki will try to retrieve the name from the MediaWiki: namespace (every page in that namespace is called a system message). For example in current MediaWiki:Sidebar: 

MediaWiki:Sidebar
...
* Interaction
** :Category:Help|help
** {{ns:Project}}:Contributing|Contributing
...

Take Interaction as example. MediaWiki will first read the message MediaWiki:Interaction/user's display language (let's say Simplified Chinese, then it's MediaWiki:Interaction/zh-hans and assuming its content is 互动). If the page is there, the page's content 互动 will substitute "Interaction". If there isn't, then the root page, if still isn't, then leave it as-is. The whole mechanism may differ since the actual mechanism goes through a long list of language fallback (still take zh-hans, it may go through /zh-hans, /zh-hant, /en, root).

So, to localize the sidebar, we will going to create some MediaWiki: pages, or system messages, and their subpages with sub-title the corresponding interlanguage link prefix. Some of the messages are already translated by MediaWiki core, and I'll list those that aren't present now. I'd suggest renaming these pages as well to have kebab-case though, and then change them correspondingly in MediaWiki:Sidebar. 

MediaWiki:Table of contents
MediaWiki:Interaction
MediaWiki:Contributing
MediaWiki:Recent talks
MediaWiki:Requests

(MediaWiki:Statistics is present due to Special:Statistics.)

Thanks! --Lakejason0 (talk) 13:52, 4 February 2023 (UTC) Reply

Sounds doable.
There's MediaWiki:vector-toc-menu-tooltip for "Table of Contents", but that one doesn't use sentence case and looking at its name, it may not be the best idea to rely on it too much.
-- nl6720 (talk) 15:48, 4 February 2023 (UTC) Reply
maybe the problem is that there isn't people providing translation. I'd say if they would like to add translations then just add a MediaWiki talk: though. Anyway, for both Chinese:
en zh-hans zh-hant note
Table of contents 目录 目錄
Interaction 参与 參與 "Interaction" is a rather formal word in Chinese (at least for simp.), translated as "Getting involved".
Contributing 贡献 貢獻
Recent talks 最近讨论 近期討論 extended from "Recent Changes", thus also need a /zh-hk with content 最近討論.
Requests 请求 請求
though, idk how MediaWiki handles Accept-Languages, but at least it would be useful for people (like me) who set interface language in Special:Preferences.--Lakejason0 (talk) 04:59, 5 February 2023 (UTC) Reply
Any progress on this? --Lakejason0 (talk) 08:50, 22 February 2023 (UTC) Reply

Intel has changed their domains and all the following links lead to some general landing page:

AltStyle によって変換されたページ (->オリジナル) /