ArchWiki talk:Requests

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

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)

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)

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)

fixed --Matthewq337 (talk) 01:35, 25 January 2026 (UTC)

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)

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)

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)

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)

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)

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)

Modification requests

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)

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

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

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

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)

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)

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)

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)

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/[YOURUUID] /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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Any progress on this? --Lakejason0 (talk) 08:50, 22 February 2023 (UTC)

Update links to Intel domains

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

• https://wiki.archlinux.org/title/Special:LinkSearch?target=https%3A%2F%2F01.org
• https://wiki.archlinux.org/title/Special:LinkSearch?target=http%3A%2F%2Fintellinuxgraphics.org
• https://wiki.archlinux.org/title/Special:LinkSearch?target=https%3A%2F%2Fcommunities.intel.com%2Fmessage

Actually all Intel links should be checked by a human, because the script used by the bot gets status 404 for most Intel links, even those that work fine...

— Lahwaacz (talk) 09:18, 30 July 2023 (UTC)

Bug migration

As announced on the Mailing list all bugs have been migrated to GitLab, and GitLab is the new bug tracker. The pages refereeing to bugs.archlinux.org (e.g. Bug reporting guidelines) must be updated to point to our GitLab.

• Special:LinkSearch/https://bugs.archlinux.org

Klausenbusk (talk) 20:42, 25 November 2023 (UTC)

fixed Matthewq337 (talk)

Reopening as there are still many obsolete links spread on the wiki. Did you check and try to update all pages in the aforementioned list? Lahwaacz (talk) 17:13, 1 December 2025 (UTC)

RFC: Vendor & Model Specific Discussion

Currently implementation detail about specific vendors and in some cases even specific models is spread out across multiple pages. This has two problems:

• As somebody without the hardware: Generic pages are cluttered with discussion that is only relevant to a subset of users.
• As somebody looking for help with specific hardware: I have to visit multiple different pages to find relevant information.

For example, if I have an ASUS laptop, I will find many things I need to know on the Laptop/ASUS page. But for some reason information on fan control is in Fan_speed_control#ASUS_laptops, there are notes about extra keys on Extra_keyboard_keys, etc.

I would like to propose that all these hardware specific sections are moved to their associated articles. This includes troubleshooting sections for specific software where the information cannot be rewritten to be useful generally.

This would NOT include separate articles about specific topics such as ASUS_Linux, Asusctl, etc that already have their own page. This would also not include example pages such as GRUB/EFI_examples#ASUS which are just using the hardware as an example.

Comic-paralyze-image (talk) 18:51, 1 March 2025 (UTC)

Dovecot 2.4

The 2.4 update to Dovecot changed the configuration syntax significantly, and previous configurations are not valid anymore. Their non-comprehensive list of changes can be found here.

As a consequence, a significant number of Wiki pages are now obsolete. This affects at least the following Wiki pages: Dovecot, Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube, SOGo, Exim.

fixed Matthewq337 (talk)

The mentioned pages are still not updated, or even marked as out of date. Lahwaacz (talk) 17:11, 1 December 2025 (UTC)

replace # dmesg with $ journalctl -k

...as this produces better formatted output (date), and can be used without root ? --Cvlc (talk) 10:49, 25 July 2025 (UTC)

👍 for replacing dmesg with journalctl, but you can't use $. See systemd/Journal#Journal access as user -- nl6720 (talk) 10:55, 25 July 2025 (UTC)

yes sorry that's what I meant. AFAIK you can't grant yourself access to dmesg by just adding yourself to wheel. Cvlc (talk) 12:50, 25 July 2025 (UTC)

I was thinking to make this happen but I noticed that just replacing dmesg with journalctl -k won't be enough; outputs should be updated as well. Getting real output for every usage wouldn't be feasible I guess. So would be just replacing the first part of dmesg output with some random dates formatted as an output of journalctl -k enough? Or wouldn't it be realistic since we would change the real output? What do you think? İsmail Arılık (talk) 08:16, 25 November 2025 (UTC)

I think it's best to start with the places where we can get real output. As for faking it, IMO we could omit the timestamp in those places. -- nl6720 (talk) 08:27, 25 November 2025 (UTC)

Fix ubuntuforums.org links

I discovered today that https://ubuntuforums.org/ silently redirects to https://discourse.ubuntu.com/ which leaves broken around 70 pages:

• Special:LinkSearch/https://ubuntuforums.org/

--Erus Iluvatar (talk) 19:45, 21 February 2026 (UTC)

some of them have a archive page ie https://web.archive.org/web/20210801003830/https://ubuntuforums.org/showthread.php?t=1458300 we can use the archive bot to do that for us https://meta.wikimedia.org/wiki/InternetArchiveBot Matthewq337 (talk) 21:25, 24 February 2026 (UTC)

We can't, the bot does not run on this wiki. And replacing dead links with a link to archive.org is not always the best solution. — Lahwaacz (talk) 10:43, 1 March 2026 (UTC)

Bot requests

Automatically add/update language links for languages hosted by external wikis

Some languages are hosted on external wikis, and I want the bot to automatically add / update language links for languages hosted on external wikis so that users do not need to add them manually. -- Blackteahamburger (talk) 15:27, 20 May 2020 (UTC)

External wikis can use different titles than "English title (Language)" and since the bot does not speak human languages, it can't figure out which links should be added on which pages. -- Lahwaacz (talk) 08:34, 21 May 2020 (UTC)

Can it be judged by interlanguage links on external wikis? -- Blackteahamburger (talk) 09:13, 21 May 2020 (UTC)

It could, but the bot would have to connect to more than one place. It might work, but it might end up even more messy than what we have now... I might try this when I have nothing better to do. -- Lahwaacz (talk) 15:32, 13 August 2020 (UTC)

Would it be possible to detect if a linked page exists or not? I've stumbled upon two laptop pages today where a japanese translation was linked but it did not exist. --Erus Iluvatar (talk) 13:55, 20 October 2022 (UTC)

Hints for Template:Broken package link

Can the hints for Template:Broken package link marked on the localization page use the localized version? This allows users who do not understand English to understand the status of the software package. -- Blackteahamburger (talk) 11:34, 26 May 2020 (UTC)

If you manually translate the hint, the bot will overwrite it to English later. Translations would have to be added to wiki-scripts, I'm not sure how to best do it. -- Lahwaacz (talk) 11:38, 26 May 2020 (UTC)

I think you can add the translations to the wiki-scripts, I think it's good. -- Blackteahamburger (talk) 11:53, 26 May 2020 (UTC)

Dead interwiki links

We already flag external links, broken packages in the repositories and AUR: could we do the same for interwiki links? I've seen a few of those manually fixed recently, in particular on translations. --Erus Iluvatar (talk) 19:41, 2 March 2022 (UTC)

That's a good idea, we just need to find someone to delegate the implementation to... — Lahwaacz (talk) 15:18, 13 March 2022 (UTC)

Remove dead translations

As you can see in Special:Diff/835558, dead translations are not automatically detected and removed. It should not be too hard to get the bot to scan for this. Bonus points if #Dead interwiki links above could also detect dead translations that are hosted on other wikis, e.g the german archwiki. -- NetSysFire (talk) 09:19, 12 June 2025 (UTC)

Flag translations that are missing the translation status template

Not all translated pages have a Template:TranslationStatus. It would be ideal if the bot can flag such pages automatically. -- NetSysFire (talk) 09:19, 12 June 2025 (UTC)

At least one translation team does not use this template on pages, and at least one page is not a translation — andreymal (talk) 10:36, 12 June 2025 (UTC)

Maybe we could just have a list of them in User:Lahwaacz.bot/Reports/problems then ?

-- Erus Iluvatar (talk) 10:54, 12 June 2025 (UTC)

Redirect removal requests

Screen

I agree with @Alad that "screen" is about "GNU screen" and their friends (especially tmux). I want to delete screen disambiguation page and rename GNU Screen to screen. How to do it right?

— Andrei Korshikov (talk) 20:13, 6 September 2025 (UTC)

Matthewq337 (talk) fixed

This is still not done. Lahwaacz (talk) 17:08, 1 December 2025 (UTC)

Lean

Could you please:

(a) remove the Lean redirect,

(b) move Lean Theorem Prover to Lean without "Leaving a redirect behind"—seeTalk:Lean Theorem Prover#Rename this page to just Lean.

— Andrei Korshikov (talk) 17:46, 9 March 2026 (UTC)

done Matthewq337 (talk) 19:15, 9 March 2026 (UTC)

Nope, you did this incorrectly again. — andreymal (talk) 21:19, 9 March 2026 (UTC)

I've renamed it but left the redirect because there are pages linking to it. — Lahwaacz (talk) 18:10, 10 March 2026 (UTC)

I've replaced all links before creating this request. Also Special:WhatLinksHere/Lean Theorem Prover says that only ArchWiki talk:Requests (i.e. this discussion) links there. What am I missing?

I want this redirect to be removed because of:

(a) it is (almost) useless—see Talk:Lean#Rename this page to just Lean for reasons,

(b) it violates "Sentence case" rule anyway:)

— Andrei Korshikov (talk) 09:10, 12 March 2026 (UTC)

Package Proxy Cache

• Special:WhatLinksHere/Package Proxy Cache — no links
• Special:PageHistory/Package Proxy Cache — no edits (pure redirect)

--Andrei Korshikov (talk) 12:19, 26 March 2026 (UTC)

DeveloperWiki:Building in a Clean Chroot

• Special:WhatLinksHere/DeveloperWiki:Building in a Clean Chroot — no links
• Special:PageHistory/DeveloperWiki:Building in a Clean Chroot — no real edits (pure redirect)

--Andrei Korshikov (talk) 13:50, 26 March 2026 (UTC)

Remove Alad for CoC violations.

Alad has broken the Code of Conduct by injecting personal politics into the XLibre entry page by personally deleting it, containing contributions of other authors over his own views of XLibre, which is separate from Arch and the ArchWiki. Arch is designed to be a pragmatic distribution which allows any customization of software and is up to the whim of the user to install. Everything about the distribution is pragmatic to say, everything is up to you, so do as you please.

If we are to be judging projects by the people in charge of them, then all entries for GNU sponsored projects should be removed due to the views and beliefs of Richard Stallman on certain sensitive topics. Unfortunately, this would destroy most of the Wiki but have to be a necessary evil if we are to uphold that XLibre be judged by the personal views of it's developer. I strongly doubt this would be tolerated because the ArchWiki is a collection of pages and a database built up over time by the users and contributions towards ArchLinux and many Arch based and even non-Arch-like distributions as a source of knowledge.

I propose Alad be removed from his position and the defaced page restored by either new contributions or a backup recovery of the defaced page. The CoC forbids the following:

"Respect other users

Arch Linux is a respectful, inclusive community. Anti-social or offensive behaviour will not be tolerated. Simply put, treat others as you would be treated; respect them and their views, even if you disagree with them. When you do find yourself disagreeing; counter the idea or the argument, rather than engage in ad hominem attacks."

"Personal topics/rants

Rants and complaints are actively discouraged. This type of content is much better suited to a blog or other personal web space and is considered undesirable in the Arch community. Your contributions should be open, productive and inviting to all participants. Also see Respect other operating systems and projects."

"Controversy/controversial topics#

There is no explicit list of topics considered to be “trollish”, controversial or provocative, but in the past, posts pertaining to Religion, Sports, Race, Nationalism and Politics have invariably been closed. Therefore, specifically avoid these and all divisive topics in the Arch community. The staff certainly realize that such issues are deeply ingrained human realities. However, this is a technical community and is not intended nor able to effectively facilitate such commentary nor the resulting unrest."

We have three separate violations. As a technical community, we leave personal politics and beliefs outside the wiki and present facts and methodology to the users in an apolitical, agnostic, and pragmatic setting that allows the read to make the ultimate choice.

Do we forbid ZFS for GPL and CDDL cross-license violations? No. We warn the end-user only, present the knowledge to use ZFS with a GNU/Linux system in any form possible, and then leave it up to the end-user to make their own determination and decision. All we do is provide a guidebook to say how to do it the best, simplest, and least obtrusive way. ReaperX7 (talk) 16:32, 17 April 2026 (UTC)

Not happening. Closing. --nl6720 (talk) 16:36, 17 April 2026 (UTC)

I don't agree with the requester's demand that the user should be removed for this. However, I genuinely think that the current situation deserves some arbitration by a neutral third party, and have made a completely separate request with a more focus on the direct situation regarding the page deletion at hand. This is not an attempt at "duplicating" this request as it has a completely different scope, I hope this can be understood. Ammonium (talk) 16:52, 17 April 2026 (UTC)

Request for arbitration regarding Xlibre page deleted for political reasons

Recently, the Xlibre page has been deleted by the user @Alad for the following reason:

The Xlibre project goes against https://terms.archlinux.org/docs/code-of-conduct/#respect and should not be listed on ArchWiki. See https://x11libre.net/#about

However, a number of users, myself included, do not believe that the given explanation is sufficient or valid to take down a wiki page. Some arguments against the decision are:

• The wiki page itself expressed itself in a neutral, non-political language. The Xlibre project is genuinely a useful project keeping X11 compatibility in the future. Having a page providing information on how to set it up is invaluable to the community, especially members who actively seek or need a modern X11 compositor.
• Off-site political comments by people involved on a project should not directly affect the status of a project on the wiki. If someone has their own political beliefs that members of the Arch community do not personally agree with, that should be okay. People have different beliefs, that's just how humans are, it doesn't mean that any software or projects those people are involved with should be immediately shunned.
• Taking down a page for "political reasons" that did not manifest within the page to start with is political bias in and of itself. User @Alad themselves did not follow the Arch Code of Conduct's section regarding avoiding controversial topics such as politics. Prior to his deletion, the Xlibre page did not discuss politics in any way, shape or form. It is only after their deliberate act that the matter became one of political opinions and the developer having some that the contributor personally disagreed with.

Some reasons for the arbitration being requested are:

• There has been a prolonged attempt on the user's User talk:Alad page trying to come up with a resolution path. However, user @Alad reacts in a dismissive and often even hostile way to any proposed resolution, quoting his replies as "I'm not going through this whole mess", implying an immediate and irrefutable dismissal of any and all disputes regarding the topic, as well as calling people trying to engage in the conversation "unreasonable". The overwhelming majority of commenters are completely ignored and have their points completely unaddressed. This has made efforts to find a direct resolultion path futile.

Unlike the above request, this is not a call to have the administrator removed, as this is not the scope of this specific request. The aim is just to have a neutral third party review this case and provide feedback on how this could be resolved. Please do not take this request as a personal attack on @Alad, I understand that they may disagree with the political statement made by some of the Xlibre developers (hey, I do too!), but their personal disagreements should not be expressed as this.

Some potential resolution paths provided are:

• Bring back the Xlibre page, with an added banner on top with a disclaimer, stating that the Arch team and community does not share the project's beliefs, and optionally note which beliefs are rejected. This resolution path has been immediately dismissed by @Alad under the assumption that "Keeping the page with a banner will likely result in the same kind of discussions we have now", but I argue that this assumption is completely unfounded, and many people, myself included, do not care about the political aspect of any of this at all, and just think that Xlibre is a genuinely useful project which documenting on the wiki would provide real informational value for the community.

Ammonium (talk) 16:50, 17 April 2026 (UTC)

> Bring back the Xlibre page, with an added banner on top with a disclaimer, stating that the Arch team and community does not share the project's beliefs, and optionally note which beliefs are rejected.

That is still taking a political stance and I am not aware of any other wiki page that has such a notice. As with most aspects of Arch users should be free to choose for themselves what to use or support with those kinds of notices reserved only for things that affect the software, the ability to run it, or has the potential to break the law. Knotrocket (talk) 18:29, 17 April 2026 (UTC)

I will second the motion for a neutral 3rd party, but at this point, can we hold trust that this and other page entries won't suffer the same fate? This shouldn't have to be a debate. An administrator breaking the CoC deliberately breaks trust with the users and contributors. This wiki is built and survives entirely on trust and to have that spoiled is extremely determental to the future of the wiki.

There shouldn't have to be a disclaimer also. There isn't a disclaimer on any of the GNU projects pages over Richard Stallman and stuff he has said either so why single out XLibre over it's creator?

@Nl6720 being entirely dismissive of even debate or discussion properly on this isn't healthy either. If we can not trust the administration of this wiki, then who can we trust?

The administration of a project must be trustworthy for a project to not only advance, but equally survive. I'm not calling for Alad to be outright banned, but reprimanded by having their administration level revoked until they can prove they are trustworthy. A 3rd party arbitration shouldn't be needed, but is welcomed. But first, re-establish trust. Uphold the CoC even to administration. ReaperX7 (talk) 22:30, 17 April 2026 (UTC)

We will not have a 3rd party arbitration regarding the Xlibre page – the Maintenance Team will decide what to do. The Arch wiki was always moderated and the Xlibre page is not the first one that got deleted. — Lahwaacz (talk) 17:53, 18 April 2026 (UTC)

All members of the Maintenance team who expressed an opinion agreed with the removal decision, closing. --Erus Iluvatar (talk) 11:42, 20 April 2026 (UTC)