ArchWiki talk:Requests

From ArchWiki
(Redirected from ArchWiki:Requests)
Jump to navigation Jump to search
Note: 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

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

Left-Handed Adjustments for Desktop Environments

I was thinking it would be helpful for lefties if there were a list of configuration options for each desktop environment that facilitate left-handed use of mice and touchpads. I'm not sure if this is related enough to Arch to include in this wiki, but I haven't had a lot of luck finding information for my own DE (KDE) let alone for others. I will start writing down information, and if no one else thinks there should be a separate page for this, I'll just add the information I find to each individual DE's page. —ajrl 2013-08-11T15:09−06:00

I think a separate page is better. -- Fengchao (talk) 11:58, 12 August 2013 (UTC)

Input methods

Currently there is no page on ArchWiki properly describing various input methods generally. There is only Localization#Input_methods_in_Xorg, but it has several problems:

  • missing descriptions
  • X compose key does not fit in
  • GTK has a default "simple" input method featuring the Ctrl+Shift+u shortcut for entering a unicode character (this was added recently into a wrong article: [1]) - again, no description
  • no description of XIM - outdated, but sometimes used as fallback?

So this is quite enough material to start a new great article ;)

-- Lahwaacz (talk) 18:23, 18 December 2013 (UTC)

Update to note: While Internationalization#Input_methods_in_Xorg itself still remains a stub, we had editors contributing language specific instructions which were set as subpages of the article:
Internationalization/Japanese and Internationalization/Korean
--Indigo (talk) 21:57, 11 January 2015 (UTC)
Localization#Input methods Section is cleaned up a little. Should we move it into Category:Input methods instead? -- Fengchao (talk) 03:53, 8 May 2020 (UTC)
As my country is currently in lock-down due to COVID-19 and I have lots of extra free time, I've decided to try and help with the various issues plaguing the ArchWiki's l10n/i18n sections. I've already started by editing the Mozc page (arbitrarily tbh, so you could always go check if my edits are OK or not) and now as a next step I'm willing to try and tackle the Input method article, if it still requires attention after the recent clean-up.
So, is there something specific that I should/could do besides editing the content? Create a new page for it? Move it to the aforementioned Category:Input methods? Thanks for any and all advice.
-- Nocifer (talk) 19:15, 20 November 2020 (UTC)
The content should not be given on the category page, categories just group related pages and sometimes give a short introduction. If you think it would be better, feel free to move the content to a separate page - there is Input method which currently redirects to Localization#Input method. -- Lahwaacz (talk) 08:32, 21 November 2020 (UTC)
Also, please see ArchWiki:Contributing#The 3 fundamental rules. -- Lahwaacz (talk) 09:44, 21 November 2020 (UTC)
Thanks for the input and also for linking the article about the 3 fundamental rules. I think I've kind of broken all of them (I ommitted the "why" part in the Edit summary, I made complex edits that replaced big parts of the content at once, and I only announced my intentions to do so after having already edited 2 articles) but in my defense the articles were in need of urgent attention due to containing lots of wrong or outdated info, they are not very popular, and last but not least I'm willing to learn from my mistakes and not repeat them in the future :)
Anyway, I've finished rewriting the Localization#Input method content, and yes, I too agree that it should live in its own page, with Localization remaining as a central hub of sort that does not contain any content itself but only links to other, more specific articles (as it already does with Fonts and Locale). So I'll move the content to Input method, and any further edits or additions that may be required to bring the content up to standards (e.g. all the stuff you've mentioned here in your first post from back in 2013) can be done there.
-- Nocifer (talk) 10:03, 21 November 2020 (UTC)
I really need to learn how to link Wiki articles in Edit summaries...
-- Nocifer (talk) 10:05, 21 November 2020 (UTC)
Alright, the new Input method page is live, and I also updated Localization#Input_method with a link to it.
-- Nocifer (talk) 10:34, 21 November 2020 (UTC)
Thanks, there are also long sections on subpages like Localization/Korean#Input methods - is it general enough to merge with the central page? -- Lahwaacz (talk) 12:23, 21 November 2020 (UTC)
Indeed it is, and I intended to try and tackle that next. All these subpages mostly just repeat the same content that can already be found in the main Input method, Fonts and Locale pages, but they concentrate and describe things in a language-specific way rather than pointing the user to the main pages where they can learn all about how locales and IMEs work. Also, they contain lots of outdated info and weird configuration tweaks that really shouldn't exist anymore.
Ideally there should be a single source of truth (i.e. the main articles) that would make it easy to edit and update the content with new information in the future, but I also like the idea of having small dedicated sections on the Localization page that can serve as a quick and dirty primer to set your system up for a specific language.
The only real issue that I can see here is that "quick and dirty" implies opinionation - someone must choose which of the multitude of IMEs and fonts to include in these sections and which ones to leave out, all the while keeping in mind that many users will probably be satisfied with "quick and dirty" and so will never visit the main pages and learn about the other options, thereby making the chosen options something like an unofficial "default" selection. That is not bad per se, but it would be unfair to the developers and packagers of the "non-default" options.
So I'm not really sure what should be done.
--Nocifer (talk) 14:28, 21 November 2020 (UTC)
I decided to revert last changes as conclusion of Talk:Localization discussion. -- Svito (talk) 21:05, 1 May 2021 (UTC)
This talk refers to older version back from 2013 [2]. Since then input methods section has been impoved and eventually split into Input method.
Of the additional points (except descriptions) still remain unadressed, but respective discussion is opened in Talk:Input method so I would consider closing this one.
-- Svito (talk) 21:05, 1 May 2021 (UTC)
I agree, the creation request has been fulfilled. Closed. -- Lahwaacz (talk) 21:11, 1 May 2021 (UTC)


I think creating a page and mentioning ways to improve sublime-text integration with Gnome would be a good idea. The trick is if you run sublime with --class=<filename of sublime text .desktop file, e.g. sublime_text_3>, it would help Gnome and XFCE to group sublime instances with its respective desktop file. This is mentioned in the comments of the aur package but I think it's better that this would be in the wiki.--183.amir (talk) 12:41, 19 December 2014 (UTC)


iPXE is a powerful network boot program with many features. Currently, there is no iPXE specific page to describe iPXE in details. There are some pages mentioning iPXE in the wiki, mostly related to network booting, without any further instruction on how to get iPXE to work. So I think it's worth to add a page with detailed iPXE explanation in the wiki. Alive4ever (talk) 10:08, 21 July 2016 (UTC)

Missing redirects

--Larivact (talk) 15:35, 21 October 2018 (UTC)


Considering SBC (single board computer) is getting more and more popular, and Archlinuxarm is growing its size, we need a proper wiki for U-boot. From my experience, a lot of things are pretty different from X86 bootloader, and I want to share to prevent newcomers from spending extra time while can only get poorly documented result.

Some difference I can think of:

Most things are memory address oriented

Unlike x86 bootloader, user only needs to specify kernel cmdline, then kernel/initramfs files. U-boot need user to load kernel/initramfs into memory and boot from memory address. U-boot expose quite a lot of details to users, which can easily make guys confused.

Device tree

Unlike X86, ARM world doesn't have comprehensive device detecting. So some hardware detection is done by device tree. In U-boot world, normally we need kernel and device tree, and optional initramfs.

Wrapped images

U-boot won't allow regular initrd/initramfs to be passed. It needs extra info to fulfill the boot protocol between the bootload and kernel. This could easily kill a lot of time searching the internet and find nothing useful.

—This unsigned comment is by Adam900710 (talk) 11:33, 12 October 2019‎. Please sign your posts with ~~~~!

A list of panel software

This is my main source when looking for new software, and there isnt an easy to find page comparing wm panels, I would expect a table with the configuration lang and feature checklist such as a notification area, motifiblity. But I didnt find it. Monkyyy (talk) 18:03, 27 January 2020 (UTC)

USB ID Repository

As described in this article, the USB ID Repository can be used to improve the information returned by lsusb. I think it might be nice to document the existence of this somewhere on the wiki, and perhaps how to use it (although perhaps that falls within the scope of a package?). — CodingKoopa (talk) 00:20, 9 September 2020 (UTC)

There is nothing to improve if lsusb already gives you a complete output, which is the case of common hardware. So the repository may be useful only for some specific hardware, it can be mentioned on pages where it is useful but I don't think we need to describe it on a separate page. -- Lahwaacz (talk) 07:29, 9 September 2020 (UTC)
Vaguely related, the Linux Hardware project may also be interesting to some, especially if trying to get hardware to work that works on another distribution.
-- NetSysFire (talk) 20:33, 1 May 2021 (UTC)

Modification requests

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.

index.php in url address

Admins of Arch Wiki, do you noticed, that in every page address begins with Why? It is uncomfortable. Why could not you do just article name after — Agent0 (talk|contribs) 22:48, 6 March 2015 (UTC)

Administrators can't configure the entry-point urls, that's something that should be done in LocalSettings.php, which however is currently unpatchable because of FS#35545.
Nonetheless I agree with you, urls could be prettified by removing "index.php/", I think has the best configuration in this respect. Documentation is in mw:Manual:Short URL/LocalSettings.php. Backward compatibility wouldn't be a problem since urls can be easily rewritten by the http server.
Kynikos (talk) 01:49, 7 March 2015 (UTC)
I have noticed, that article's path became Better, but still with ugly index.php. I agree with you, french arch linux wiki did varian which I wanted: just clearly But according to [3] it is not recommended in some cases. As I understand, it just do not allow you (Pierre) to use some titles as articles, for example, but really, what reason to have such articles =D. And another problem may be that it may require root access to hosting server. Does is running on virtual server or it is hosted on a normal server? — Agent0 (talk|contribs) 09:59, 17 August 2015 (UTC)
This could now be done, seeing as FS#35545 has been implemented. — Ekkelett (talk) 06:53, 6 March 2017 (UTC)
Good point. Instead of totally shortening it, we should follow [4] in my view. The french version appears to be ending in what's referred to as unsupported configuration in [5] and you don't want to make things like processing robots.txt complex, because it will likely reveal bugs in proxies we don't want to care about. --Indigo (talk) 10:57, 6 March 2017 (UTC)
For the records at least also KDE UserBase uses root titles, but I agree that it's better to keep a prefix. Wikipedia and Gentoo use "wiki/", while uses "title/". In our case I'd avoid "wiki/" since we already have it in the third-level domain; I like "title/", but also "w/" or "t/" are interesting options. — Kynikos (talk) 08:44, 7 March 2017 (UTC)
I may have been too quick dismissing root titles, just saw the unsupported statement and because of that thought it's more to it than the favicon.ico example used above. We could ask devops about opinion in due course. Regarding a prefix: A singular "w/" or "t/" is not self-speaking as "title/", I like that too. --Indigo (talk) 15:31, 10 March 2017 (UTC)

This could be implemented soon as a solution to an unrelated issue. It seems that the wiki's robots.txt is not very good, because the standard has only the notion of "directories" so we can't effectively block "dumb" crawlers who may not support complex matching like "/index.php?diff=". This may have lead to enabling the Lockdown extension [6][7] which prevents public access to archived pages etc. If we use short URLs, e.g. with "/wiki/" as $wgArticlePath and "/w/" as mw:$wgScriptPath as recommended in Manual:Short URL, robots.txt would be as simple as

User-agent: *
Disallow: /w/
Disallow: /index.php
Disallow: /skins/

But this assumes that MediaWiki is installed to "/w/" rather than the webroot ("/") which is the case now, so it would have to be moved. It would be simpler to keep it in the webroot, keep $wgScriptPath empty ("") and explicitly allow the path for $wgArticlePath:

User-agent: *
Allow: /wiki/
Disallow: /

Note that the Allow directive is non-standard, but bots who don't support it would be simply unlucky :-)

So, the main question is what do we use as the $wgArticlePath? To summarize some options:

  • /wiki/ (used on Wikipedia, but duplicates our "wiki" subdomain)
  • /w/ (shorter, used as $wgScriptPath on Wikipedia)
  • /title/ (my personal favourite after re-reading the discussion above)
  • /t/
  • /article/
  • /page/

-- Lahwaacz (talk) 16:04, 19 April 2020 (UTC)

I vote for /wiki/. -- nl6720 (talk) 18:27, 19 April 2020 (UTC)
3 years and still in love with /title/ here. -- Kynikos (talk) 15:39, 21 April 2020 (UTC)
How about /view/ as another alternative? Other than that, /title/ works for me. -- Alad (talk) 09:56, 25 April 2020 (UTC)
Is that "view" a noun or a verb? I think it's more natural to use nouns in the URL, but this wouldn't fit as a noun... -- Lahwaacz (talk) 10:04, 25 April 2020 (UTC)
I'd say a noun, but I can see how it would be ambiguous. Let's go with "title" then. -- Alad (talk) 00:32, 29 April 2020 (UTC)
It'd be good to read /page/ in the URL if /wiki/ is not desired. -- samuelrajan747 (talk) 17:55, 12 July 2020 (UTC)
+1 for /title/, because it matches index.php?title= -- Svito (talk) 17:58, 12 July 2020 (UTC)
+1, I also think /title/ is better. -- Blackteahamburger (talk) 01:34, 13 July 2020 (UTC)
I have created a MR[8] for this, so we can get the ball rolling. Can I get a final ack, that /title/ is what you want? Klausenbusk (talk) 14:59, 20 March 2021 (UTC)
Oh wow, thank you, I'm still a /title supporter. -- Kynikos (talk) 11:32, 21 March 2021 (UTC)
Yup, /title looks okay to me. -- NetSysFire (talk) 18:59, 29 March 2021 (UTC)
This is now deployed, closing. -- Lahwaacz (talk) 20:10, 1 May 2021 (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)


The FAQ could use an entry like "After upgrading my kernel, I can't mount USB devices", preferably linking FS#16702. See [9] for a case where users are not aware of this. -- Alad (talk) 22:55, 18 September 2015 (UTC)

+1, but I'd place it into General troubleshooting. -- Lahwaacz (talk) 07:52, 19 September 2015 (UTC)

Drop of i686 support

Following [10] I've done these edits for the moment:

There are so many other articles that need updating, and also the edits above will need to be amended after November 2017. I think it's better to decide here whether we remove all the i686 content immediately, or we keep it until the final deprecation and do the cleanup then.

Kynikos (talk) 08:57, 26 January 2017 (UTC)

Hi, I think for some of content it will depend on further decisions of the devs along the timeline, e.g. will there be changes to arch= options. We should wait a little to see how the migration plan looks like. IMHO it is useful to start updating once a topic is clear, i.e. before the deadline. Another moving target is whether a community effort to keep i686 somewhat establishes itself; any such would have an impact on what to change how.
In general I believe the related content changes will be so wide ranging that we should open a Archwiki:Requests/Drop of i686 support (or a top-level link like Archwiki:Drop of i686 support - easier to crosslink) to link to from here. Better to keep overview.
--Indigo (talk) 09:32, 27 January 2017 (UTC)

I think it's good to keep Migrating between architectures around, it's also linked at least from the FAQ.

Kynikos (talk) 08:57, 26 January 2017 (UTC)

About Makepkg#Build 32-bit packages on a 64-bit system and Install bundled 32-bit system in 64-bit system I'm not sure, perhaps they may be useful for somebody during the transition?

Kynikos (talk) 08:57, 26 January 2017 (UTC)

schroot redirects to Install bundled 32-bit system in 64-bit system. I think we should continue to have a page showing an example of setting up an schroot. It's sometimes useful to run Fedora, Ubuntu, etc in schroot. I suppose the article should be altered (and re-titled) to use something other than 32-bit Arch as the example. Bobpaul (talk) 17:46, 17 July 2017 (UTC)
Looks like Install bundled 32-bit system in 64-bit system has been archived, but there are still some incoming links. There is also Building 32-bit packages on a 64-bit system but I don't know how outdated that is. Lonaowna (talk) 14:34, 14 December 2017 (UTC)
In the end, with no official repository of i686 dependencies to build against, there is no longer any method of building natively 32bit packages in Archlinux (the only way to do so would be to create a build chroot using Archlinux32's repository). There's probably very little use for this anyway and as such, I've archived the relevant pages. quequotion (talk) 14:53, 5 June 2019 (UTC)

For some x86_64 capable hardware there are 32-bit UEFI restrictions. Example section: Unified Extensible Firmware Interface#UEFI Firmware bitness. It needs to be checked whether i386.efi bootloader files will continue to be built after i686 is dropped (FS#52772). Depending on result, it may be useful to rebase Category:Boot loaders content to x86_64 early on?

--Indigo (talk) 08:45, 30 January 2017 (UTC)

Turns out my prior research was bad, 32-bit efi files are not packaged anyhow. Hence, users requiring those need to generate them, see FS#52772 for details. Still it is useful to weave this info in when references to i686 are eliminated in Category:Boot loaders articles. --Indigo (talk) 09:24, 2 February 2017 (UTC)


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)

Templates & pages that need to be modified

I am modifying the template to deprecate Template:META Box Red, Template:META Box Blue and Template:META Box Green, but I cannot modify the Arabic template (probably because Arabic is arranged from right to left). These templates need to be modified:

Some Arabic pages also need to be modified, see Special:WhatLinksHere/Template:META_Box_Blue, Special:WhatLinksHere/Template:META_Box_Red and Special:WhatLinksHere/Template:META_Box_Green.

-- Blackteahamburger (talk) 16:53, 11 June 2020 (UTC) (EDIT: 11:20, 31 July 2020 (UTC))

I've done Warning, Note and Tip, but yeah the rest gets trickier... -- Kynikos (talk) 11:40, 13 June 2020 (UTC)
It seems that this can only be modified by Arabic users... -- Blackteahamburger (talk) 11:59, 13 June 2020 (UTC)
See also [11]. -- Kynikos (talk) 04:05, 14 June 2020 (UTC)
If Red, Blue and Green are deprecated, probably Template:META Box Yellow should follow, or be renamed to something more meaningful. -- Kynikos (talk) 04:22, 14 June 2020 (UTC)

dmesg & journalctl prompt

All officially supported kernels (except for linux-lts) have SECURITY_DMESG_RESTRICT=y, meaning dmesg must be run as root. So all instances of $ dmesg should to be replaced with # dmesg. At the same time, I think the same should be done for $ journalctl# journalctl. To read the journal you need to be in the adm, wheel or systemd-journal groups and while that will most likely be the case for most single-user systems, I don't think it's correct to rely on that. The only exception is when looking at the user service journal or using journalctl --user. -- nl6720 (talk) 11:05, 8 January 2021 (UTC)

I think I have tackled most of the $ dmesg to # dmesg changes for English articles. I did not do much regarding $ journalctl though, so there's still work to be done there. -- Flyingpig (talk) 11:33, 21 April 2021 (UTC)
I've finished making the dmesg user prompt messages for most of the non-English articles as well. The articles that I left alone used regular user prompts (i.e., $) inside of a Template:ic. Changing those would require adding a small note about running the command as root in the articles' respective languages. The only articles that do this (as far as I know) are the translated versions of Migrate installation to new hardware hosted on
The Japanese version of the article also does this, but it's hosted on an external wiki.
-- Flyingpig (talk) 02:28, 25 April 2021 (UTC)
I've finished changing instances of $ journalctl to # journalctl where appropriate (i.e., not for invocations of journalctl --user) in articles that I could find in the mainspace. I have deliberately left the (outdated) translations of systemd untouched because the English article (as it stands now) does not mention journalctl in any Template:bcs or Template:hcs—updated translations would not either. The same goes for Network Time Protocol daemon (简体中文). -- Flyingpig (talk) 04:05, 1 May 2021 (UTC)
Good work! If you're up for it, feel free to tackle dmesg and journalctl in Template:ic. E.g.: run journalctl -b as root to.... See the first bullet point of Help:Style#Command line text. -- nl6720 (talk) 06:13, 1 May 2021 (UTC)
I've made the appropriate changes for English articles in the mainspace containing dmesg or journalctl. I haven't made these changes for non-English articles since I don't know how to write "as root" in that many languages. -- Flyingpig (talk) 19:16, 1 May 2021 (UTC)
Good work, I think that's enough to close this request. Translations will catch up sooner or later and update the wording according to English pages. -- Lahwaacz (talk) 20:09, 1 May 2021 (UTC)

Bot requests

Here, list requests for repetitive, systemic modifications to a series of existing articles to be performed by a wiki bot.

Package links to wiki links

It'd be nice if a bot went around changing links to packages that have a wiki entry to links to the wiki entry (e.g. change git to git), possibly also for aur packages (e.g. dropboxAUR to dropbox). Jabranham (talk) 19:42, 31 July 2018 (UTC)

It's not that simple because package links like in git#Installation, List of applications and probably many other places should not be replaced. -- Lahwaacz (talk) 19:35, 11 August 2018 (UTC)

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)

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)

Arch's git URLs

Sooner or later will cease to exist. It's not clear when (or if) there will be redirects and after a project has moved to, the repo in might not get updated anymore. Lets prepare to update the links in the wiki pages.

archiso, aurweb and infrastructure

archiso, aurweb and infrastructure are on

-- nl6720 (talk) 14:03, 25 July 2020 (UTC)

Hmm, GitLab doesn't return 404 for non-existent files. This complicates things. -- nl6720 (talk) 11:57, 27 July 2020 (UTC)
Well, it gives 302, which we can treat as invalid - we don't want any of the replaced links to become a redirect. Should work with [12]. -- Lahwaacz (talk) 08:40, 28 July 2020 (UTC)
Without following redirects we'll have those ugly URLs with /-/ in them, but that's tolerable.
A real issue is that GitLab uses blob for files and tree for directories, (they are interchangeable and GitLab redirects to the correct one), but uses tree for both.
-- nl6720 (talk) 13:04, 4 August 2020 (UTC)
I added some post-processing based on our IRC discussion. It took me quite some attempts, but this should finally work. Blobs and trees are replaced correctly, but I might have already migrated some links with an older version of the script... If you care a lot, we could add a dummy replacement from to and let the new code do its thing with the redirect replacement, otherwise we can leave it like that. -- Lahwaacz (talk) 19:27, 4 August 2020 (UTC)
I just checked and by sheer luck, there are no links with mismatched "blob" and "tree". However, a totally embarrassing error is that I was still using "" in the edit summaries... /o\ Lahwaacz (talk) 19:48, 4 August 2020 (UTC)
I manually updated a link that links to commits of a specific author. Creating a regex for it would not be worth the effort. -- nl6720 (talk) 12:46, 4 August 2020 (UTC)
I think I flagged all the dead links (I'm aware that I could have just fixed some of them). Only links to archiso's udev rules remain unflagged since the repo on isn't getting updated. -- nl6720 (talk) 08:47, 5 August 2020 (UTC)

KDE migrated to a hosted GitLab instance so all their git repos moved from to

All links listed in Special:LinkSearch/ are dead and should be updated to their equivalent.

-- nl6720 (talk) 10:32, 28 December 2020 (UTC)

Okay, I've finished updating the links listed in Special:LinkSearch/ -- Flyingpig (talk) 08:08, 2 May 2021 (UTC)
Thanks! — Lahwaacz (talk) 08:15, 2 May 2021 (UTC)