Difference between revisions of "ArchWiki:Requests"

From ArchWiki
Jump to navigation Jump to search
(too dangerous to do with a bot, move back to normal requests)
Line 475: Line 475:
:::::::::We can re-use the advice to fix the link that led the user there in the redirect for simply-archived pages, although it will make sense only for external/full links, as a good admin will have fixed all the internal backlinks before archiving or deleting an article. About your idea in general, we can already check [[Special:WhatLinksHere/Template:Deletion]], there's no need for a "temporary redirect" after the page has been marked for deletion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:59, 22 August 2014 (UTC)
:::::::::We can re-use the advice to fix the link that led the user there in the redirect for simply-archived pages, although it will make sense only for external/full links, as a good admin will have fixed all the internal backlinks before archiving or deleting an article. About your idea in general, we can already check [[Special:WhatLinksHere/Template:Deletion]], there's no need for a "temporary redirect" after the page has been marked for deletion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:59, 22 August 2014 (UTC)
::::::::::Ok, no change deemed necessary then. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:11, 22 August 2014 (UTC)
==== List of suggested solutions ====
==== List of suggested solutions ====

Revision as of 16:11, 22 August 2014

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

See ArchWiki:Reports to report questionable contributions. Please sign your edits and feel free to comment on others' requests.

General requests

Inaccurate content
Pages flagged with Template:Accuracy.
Outdated content
Pages flagged with Template:Out of date.
Irrelevant or unhelpful content
Pages flagged with Template:Deletion.
Incomplete content
Pages flagged with Template:Expansion.
Poorly-written content
Pages flagged with Template:Poor writing.
Duplicate effort or overlapping scope
Pages flagged with Template:Merge.
Misleading names
Pages flagged with Template:Moveto.
Poor translations
Pages flagged with Template:Bad translation.
Incomplete translations
Pages flagged with Template:Translateme. See also ArchWiki Translation Team.
Incomplete content
Pages flagged with Template:Stub.
Dead or broken links
Pages flagged with Template:Dead link. Should be repaired or replaced.
Templates with an undefined parameter
Pages automatically flagged with Template:META Error
Unexplained presence of an article status template
Pages automatically flagged with Template:META Unexplained Status Template.
Application listed without links to packages
Pages automatically flagged with Template:META Missing package.
Pages with misspelled or deprecated templates
Need to fix template or change to new template.

Problem redirects

Note: Redirects should not point to other sites and ones that do sometimes erroneously show up on these pages.

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


How to configure SAMBA PDC + LDAP in Arch Linux? (Moved from another page. Hokstein 19:57, 16 September 2007 (EDT))


Finding information on the install of this program already requires a bit of searching around the net, and then a variety of modifications to get it running correctly. It would be nice to have a good HowTo about the install and setup of Tripwire on Arch. The package is availabe in community.

It has since been removed from [community], it's in the AUR now. -- Karol 21:52, 29 August 2011 (EDT)

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 Internationalization#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)


An article, or even stub that links to resources, explaining what DRI is, why it's important, differences between DRI 1, 2, 3, how DRI1 is no longer supported as of xorg-server 1.13, simple xorg.conf code explaining the DRI section, enabling the composite and render extensions there, these and more. Just my thoughts.


ldns is a core package with no wiki documentation. It is also relatively new in the world of DNS tools and is not well covered on the Internet. Documentation of basic features and what it is not (eg a replacement for bind) would provide a valueable resource. MichaelRpdx (talk) 20:07, 17 February 2014 (UTC)

The description of the ldns package is "Fast DNS library supporting recent RFCs". The official homepage mentions that several example programs are included with the library, the official docs is probably best for programmers. -- Lahwaacz (talk) 21:37, 17 February 2014 (UTC)


Surprisingly, there is no wiki page describing the installation and configuration of Perl, unlike Python, Ruby etc. Could include the installation of CPAN modules and a list of good tutorials for beginners, too. So far there is only guides for packaging Perl and its modules (Perl Policy and Perl Package Guidelines respectively) -- bluestreak0 01:32, 17 April 2014 (UTC)

Xen: Creation of a network bridge

I cleaned up the Xen article as much as I could. I can't get past the "Creation of a network bridge" section as it only describes how to do that with netctl. Maybe someone more experienced with Xen can expand on how to do that with other network managers?

UPDATE: See Network bridge, this request should be implemented there. axper (talk) 07:32, 20 July 2014 (UTC)

Linux console

I was thinking that a new page for the console would be a good idea. The Wikipedia:Linux console article gives a short general overview, but obviously doesn't concern the configuration. Since it's an independent system, configured separately from any graphical environment, it would bring together several related sections across multiple articles in one place. It's a fairly complex system and difficult to cover in any depth in small sections across other articles (such as Fonts). I've put together a basic example, User:Teppic74/Linux_console. -- Teppic74 (talk) 17:11, 3 July 2014 (UTC)

Sounds interesting, but I don't know how deep you want to go in the description, it may be too much for a single page as, according to your outline, the resulting article would cover all Fonts#Console fonts, Keyboard configuration in console, part of Extra Keyboard Keys, Map scancodes to keycodes and Extra Keyboard Keys in Console. The keyboard configuration is split mainly because the configuration for Xorg is connected to it, I don't know how this would be done if the low-level description is moved. On the other hand, some of these articles could use some reorganization, so it may still be possible... -- Lahwaacz (talk) 13:17, 4 July 2014 (UTC)
I feel this is part of the problem, that the details concerning the console are tacked on to other articles rather than being naturally associated with them. As things stand, I think the documentation is lacking. I don't think a huge amount of information is needed, it would just be helpful to be in one place, as the console is mostly isolated from the rest of the system. The other articles could link to the console article for further details. Another possibility is separate articles exclusively for the console display and keyboard, but they're obviously part of the same topic. -- Teppic74 (talk) 18:48, 4 July 2014 (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 #General requests 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.


Many pages are out of date and I can't even flag them out of date. Should users be warned that pages in this "category" may be really old and abandoned? -- Karol 09:19, 8 October 2011 (EDT)

Perhaps we can create a special template to be included at the top of every article in that category? -- Kynikos 13:41, 8 October 2011 (EDT)
Just a note: some of these pages are in Category:DeveloperWiki, some in Category:Arch development and some in both :\ -- Lahwaacz (talk) 08:42, 10 July 2014 (UTC)

Move/Merge articles to external wikis

Although Finnish and Serbian have their own wikis, we're still hosting some articles in those languages:

Some users of those wikis should probably be contacted in order to complete the move/merge, replacing those articles with interlanguage links at least on the respective English pages.

-- Kynikos (talk) 16:34, 10 May 2012 (UTC) (Last edit: 03:04, 22 September 2013 (UTC))

New dependencies for pacman

Some parts of the wiki may need updating, e.g. Pacman#Q:_Pacman_is_completely_broken.21_How_do_I_reinstall_it.3F (the last one in the FAQ). -- Karol 08:39, 20 January 2012 (EST)

There are actually quite a few dependencies that aren't mentioned, since a broken dependency of pacman would also break pacman (can see them all with pactree -l pacman | sort -u | cut -f 1 -d ' '). The packages that would need to be downloaded and extracted would vary depending on which partial upgrade was done. thestinger 15:19, 21 February 2012 (EST)


Instead of flagging all articles still using the old kernel image naming out of date, can we do some mass-renaming? -- Karol 20:55, 20 October 2011 (EDT)

Last week, I found at one article that was using vmlinuz26 in an example for users of non-recent kernel versions. I'm not sure if we would want to keep such an example around, but we may want to decide that before doing a mass rename. And for what it's worth, I don't think it is necessary to keep such antiquated examples around. -- Jstjohn (talk) 20:53, 4 June 2012 (UTC)
Of course I don't know what article you're referring to, but doing a mass-renaming with a bot sounds a bit dangerous, because as you've pointed out there may be exceptions where the old kernel names are still ok. I'm moving this discussion out of Bot requests. -- Kynikos (talk) 14:57, 5 June 2012 (UTC)
The rename is done very long time ago. I am stating to do the following except few places as mentined above.
  • vmlinuz26 to vmlinuz-linux
  • kernel26.img to initramfs-linux.img
  • kernel26-fallback.img to initramfs-linux-fallback.img Done
-- Fengchao (talk) 05:40, 26 September 2012 (UTC)

Switch initscripts to systemd on all pages


Now that initscripts no longer are supported, we should change stuff that have information with initscripts to systemd --Toringe (talk) 22:49, 23 March 2013 (UTC)

Agree, all initscripts should be converted to systemd. Many old stuff could be removed safely now. -- Fengchao (talk) 01:25, 24 March 2013 (UTC)
D-Bus has nothing to do with initscripts deprecation, closing. -- Lahwaacz (talk) 21:04, 29 November 2013 (UTC)
What should we do with articles that mention rc.conf etc? If I'm not going to fix them, is it OK to mark them as out of date like Very_Secure_FTP_Daemon#Using_xinetd and then consider the wiki switch to systemd as complete? -- Karol (talk) 12:05, 14 December 2013 (UTC)
Yes please, go the Out-of-date template way, it will be more effective than this discussion. -- Kynikos (talk) 03:49, 15 December 2013 (UTC)

ConsoleKit and D-Bus

polkit rebuild

ConsoleKit support has now been fully dropped from all packages in the repositories. There is no need for ck-launch-session and friends after this moves.

Please use link to General troubleshooting#Session permissions to replace anything mentioning ck-launch-session, dbus-launch, problems with consolekit/logind, etc.

-- thestinger (talk) 04:40, 26 September 2012 (UTC)

ck-launch-session dbus-launch and friends

We can remove every single mention of ck-launch-session on the wiki - consolekit support has been dropped upstream and Arch is going to drop it from all the other packages too. This was also never actually needed, since a session is already started with pam, and you simply needed to keep the session on the same tty. Using dbus-launch is usually not needed at all, and should be removed almost everywhere too. -- thestinger (talk) 18:56, 20 October 2012 (UTC)

I decided just to get this right once and for all in xinitrc with the xinitrc.d snippet to start dbus, and preserving the session by keeping X on the same tty (which works with both logind and ck). It also avoids all the things that can go wrong with ck-launch-session (dbus being started first, for one). thestinger (talk) 22:24, 24 October 2012 (UTC)
--Fengchao (talk) 01:23, 18 April 2013 (UTC)
Status update: all pages inappropriately using ck-launch-session are marked as out of date, the only English page falling into this category is Joy2key. The number of localized pages in that list is quite high though, this issue should get some more attention. Pages also currently mention "consolekit" (the third link) only regarding its deprecation. -- Lahwaacz (talk) 11:46, 30 November 2013 (UTC)

virtualbox-iso-additions & Co. package name changes

I guess virtualbox-iso-additions is now called virtualbox-guest-iso. There are other changes (virtualbox-modules -> virtualbox-host-modules, virtualbox-source -> virtualbox-host-source) but the old names are not used in English articles. There may be some other changes (new names, changes to how things work), I only edited that one thing because I know nothing about virtualbox. If no more edits are needed, feel free to close this request. -- Karol (talk) 08:58, 23 September 2012 (UTC)

Inconsistent block size value for dd command

There are many examples of the dd command on the ArchWiki and they use various values for the block size option. There seems to be a lot of confusion about what value to use. This is exemplified by the Using DD for disk cloning question on Server Fault. I have also collected a few examples from the ArchWiki (see: User:Filam/Block size#Disparate examples). In order to make these examples more consistent I would like to either write Block size or Dd. Then any examples could be replaced by references like the Package management style rules. What do you think of that plan?
-- Filam (talk) 19:45, 24 September 2012 (UTC)

Can you give a more explicit example? For instance, how would you change this extract from User-mode_Linux#Build_rootfs_image:
1.) First you have to create a single, big file into which you will install Arch Linux. This command creates a single 1 GB file, only containing zeros - should be enough for a basic Arch Linux installation.
dd if=/dev/zero of=rootfs bs=1MB count=1000
-- Kynikos (talk) 12:36, 25 September 2012 (UTC)

Move openjdk6 to jdk7-openjdk

Developer annourcement: OpenJDK6 packages will be removed by the end of this month.

All users should move to OpenJDK7 based packages jre7-openjdk/jre7-openjdk-headless/jdk7-openjdk (or the Oracle based JRE/JDK from AUR) very soon.

The next OpenJDK7 update will replace openjdk6 on the system.

There are many openjdk6 exist in Arch wiki. All of them should be removed or changed to openjdk7.

compiz and emerald got dropped to AUR


sysvinit also got removed.

I've done some updating (just the English articles), so this is more of a heads-up for anyone taking care of non-English articles or people who would like to double check if I missed something / messed something up. I don't know if e.g. this or this is the right way to approach a situation where 'foo' package is neither in the AUR nor in the repos, but there may be 'foo-git' or 'foo-no-gnome' in the AUR. It seems to clash with ArchWiki:Requests#Use_AUR_templates. I've noticed that if there's a 'foo-git' package in the AUR, when 'foo' gets dropped from the repos, no dev / TU uploads 'foo' package to the AUR - makes sense, but makes updating the wiki harder ;P

I didn't fix Emerald because I don't know which package in the AUR - if any - represents the 'standard Emerald themes'. The link to emerald needs to be updated the sentence rephrased, as it's not in the repos anymore.

Apart from that one edit, I didn't touch compiz, as it needs more extensive editing and I know nothing about it compiz. Sure, I can just remove the parts that are outdated (e.g. referring to the removed package groups) but maybe someone can do a nicer rewrite.

List of recently removed packages / package groups:


-- Karol (talk) 22:53, 21 May 2013 (UTC)

libgl and libgl-dri are no more

Quite a few articles mention these packages. I think that instead of libgl they should point to mesa-libgl or nvidia-libgl. libgl-dri is not provided by any package. -- Karol (talk) 12:47, 26 May 2013 (UTC)

libgl is a virtual package that is provided by multiple other packages:
- mesa-libgl, nvidia-libgl, nvidia-304xx-utils from extra
- catalyst-utils, catalyst-utils-pxp from the catalyst repos
- mesa-libgl-git and probably many more from AUR
You can even do pacman -S libgl, and it will ask which one you want to install (of course it will only list the ones from repos that you have added to /etc/pacman.conf). Thus using "libgl" as a package/dependency name is in fact correct, and should be preferred in places where we don't care about which specific graphics driver is used.
--Sas (talk) 18:28, 9 January 2014 (UTC)

Automatic loading of kernel modules

There are notes like "Since kernel 3.4 all necessary modules are loaded automatically" and "Newer versions of udev load the module automatically", which are usually followed by rather long section "If that does not work, do modprobe foo" and "To make it permanent after reboot, add the following to /etc/modules-load.d/module.conf".

Examples: Kernel_modules#Configuration, CPU frequency scaling, CPU frequency scaling#CPU_frequency_driver, Network configuration#Check_the_driver_status, Wireless_Setup#Device_driver.

There are several problems with this, so quick list of tasks:

-- Lahwaacz (talk) 19:09, 5 August 2013 (UTC)

As the minimum supported kernel version is apparently 3.10 at the moment, we should get rid of those modprobe commands and just link to Kernel_modules#Configuration. -- Lahwaacz (talk) 21:02, 29 November 2013 (UTC)

Help me rewrite the eCryptfs article

Not sure if this is the correct place to post this, but I'd like to let the admins/maintainers and other interested Arch wiki editors know of my plans for the eCryptfs article, which I have laid out at Talk:ECryptfs#Major_restructuring/rewrite. If there are any objections, or suggestions for how to do it better, it would be nice to hear them early on.
Also, since it's a relatively big task, it will take a long time to complete if I remain on my own. So feel free to join me! :)

Links to Gentoo wiki

http://en.gentoo-wiki.com/ is offline for some quite time now, the new address is http://wiki.gentoo.org/. There are several links that need to be updated: [2]. I don't really know what (and when) happened there, I just suppose that there has been some major restructuring of the Gentoo documentation - there is not direct 1:1 mapping of the old links to the new address, so it will have to be done manually. -- Lahwaacz (talk) 14:06, 22 February 2014 (UTC)

Actually, there is Gentoo Wiki Archives, but is it safe to link there considering that it is read-only? -- Lahwaacz (talk) 22:27, 6 March 2014 (UTC)
http://wiki.gentoo.org/ is of course preferable, however if there's really no alternative and the article in the Archives is still relevant, the fact that it's no longer editable shouldn't prevent from linking there. -- Kynikos (talk) 01:43, 8 March 2014 (UTC)

Cleanup: installation category

Category:Getting and installing Arch needs a serious cleanup, there are many outdated and/or inappropriate pages. I don't know if my perception of these pages isn't too radical, feel free to comment and possibly hold me down a bit.


Seriously outdated:


-- Lahwaacz (talk) 22:08, 6 March 2014 (UTC) -- edited on 17:18, 11 July 2014 (UTC)

Agreed, I'll scratch fixed articles off the list. -- Alad (talk) 21:04, 31 July 2014 (UTC)

Cleanup: links to non-existent packages

As of today, there are exactly 714 invalid uses (413 unique) of Template:AUR or Template:Pkg, spread across 398 pages. The complete list is on User:Lahwaacz.bot/Report 2014-04-05. I will try to go through it and update the links, but this is not a one-man job, so I would really appreciate some help. Please remember to strike/remove the items from the list to save others' time. -- Lahwaacz (talk) 16:42, 5 April 2014 (UTC)

The previous report is closed for further updates, please contribute to User:Lahwaacz.bot/Report 2014-05-11. -- Lahwaacz (talk) 09:15, 12 May 2014 (UTC)

Surrounding link text

While performing #Cleanup: links to non-existent packages, the bot updated a lot of package links, but of course it couldn't update the text around them accordingly, for example [3], so that's something else that could be done. Here's the list of the changes: [4]. -- Kynikos (talk) 03:24, 7 April 2014 (UTC)

Technical detail: the last link is now slightly inaccurate, it shows all edits of the bot made in April 2014. Is there a way to set a specific day? (in this case 5th April) -- Lahwaacz (talk) 21:46, 9 April 2014 (UTC)
Cool, there's really a way, I've just noticed it :D https://wiki.archlinux.org/index.php?title=Special:Contributions&target=Lahwaacz.bot&offset=20140406000000 (the magic is in the offset parameter!) -- Kynikos (talk) 13:51, 11 April 2014 (UTC)
Update: the edit list for the 2014-05-11 cleanup is [5]. -- Kynikos (talk) 09:42, 12 May 2014 (UTC)

Add missing interlanguage links in protected pages

Some protected pages lack respective interlanguage links even though translated pages exist (for example, Installation guide). --Kusakata (talk) 16:49, 1 July 2014 (UTC)

I've fixed Installation guide, I can't check all the other pages now, if you find some other missing links somewhere else, please report it in that article's talk page. A little tip to find all the localized versions of the same title is to preview one article adding Template:i18n (no need to save of course). -- Kynikos (talk) 07:31, 2 July 2014 (UTC)
Thank you. I found: Category:Help (lacks ja, uk, zh-TW links), The Arch Way (su), Arch Linux (su), Installation guide (bg (its name is Official Installation Guide)), lt (Quick Arch Linux Install), nl (Official Installation Guide), th (Quick Arch Linux Install)), Arch packaging standards (ja, pt), Archboot (ar), and Help:i18n (ja).
Well, thank you for your reserach, it's all fixed except for the Finnish links, which would point to the external wiki; all the Finnish articles hosted in this wiki should be moved there. -- Kynikos (talk) 09:51, 3 July 2014 (UTC)

Should we remove or archive obsolete articles?

Ubuntu One is one I stumbled upon. I think it can be safely deleted. -- Karol (talk) 19:22, 30 July 2014 (UTC)

Could you explain in more details what you mean by archiving and deleting? I am all against completely removing information from public viewing however.
axper (talk) 15:44, 31 July 2014 (UTC)
Deleting means we remove the article and archiving means we e.g. lock the page or just add a note / warning at the top, saying that it's obsolete, not used anymore. Initscripts/rc.conf would be another such page. -- Karol (talk) 21:45, 31 July 2014 (UTC)
Well, Ubuntu One is discontinued and the related AUR packages are deleted, I would really delete it, @axper do you have any particular objections?
About Initscripts/rc.conf, there has been some work done in init, and its content may be re-used for the initscripts fork?
-- Kynikos (talk) 06:41, 2 August 2014 (UTC)
About deleting articles from wiki in general: Any article is documentation and deleting it wrong in my opinion. For example someone might want to design a similar program in the future find the information useful. Or some historian/statistican interested for example why the particular program failed to gain traction. Or Wikipedia or a similar resource might might use our articles for citations. Or the program might still be used by stable/old distros. Or finally, the project might be revived in the future!
I vote for archiving:
  1. Add a corresponding notice at the top of the article
  2. Remove the article from category pages
  3. Remove all links to that article from this wiki
Or if Mediawiki has any support for archiving - move such articles to separate namespace/whatever (needs more research).
axper (talk) 16:32, 2 August 2014 (UTC)
With MediaWiki, nothing is ever really deleted; deleted pages are just hidden from regular users. IMHO, deleting instead of archiving results in much cleaner wiki in general (mostly categories and search results). Also, unlike deletion, there is no "Archive" button, so every archival solution is very laborious. -- Lahwaacz (talk) 16:55, 2 August 2014 (UTC)
hidden from regular users has mostly same effects as deleted, because it's accessible only by half a dozen chosen individuals. See the reasoning in my post above.
About cleaner wiki:
  1. Categories: Just remove the page from category
  2. Search results:
    • Mediawiki search results: By default only (Main) namespace is searched. So a separate namespace would solve this.
    • Google/other search engines: Nothing can really be done (or should be done). If someone searches for "ubuntu one" and finds our archvied page, it's very normal behaviour!
I don't think moving to separate namsepace is a lot more laborious than pressing "delete" button.
Solutions other than separate namespace should be considered as well I think.
axper (talk) 17:52, 2 August 2014 (UTC)
Any archive would have to be organized in order to be useful. I don't think we have the manpower to do this even if archiving required just clicking a button. Also, I don't think that ArchWiki is intended to be a (partial) archive of any kind.
Regardless, dead projects are quickly forked if they were really useful and died just because of the maintainer's lack of time, or they are lost forever regardless of the archived documentation. I don't see why we should keep a page about projects dead for ~5 years, the more when upstream has its own documentation archived.
-- Lahwaacz (talk) 18:12, 2 August 2014 (UTC)
I counted only 25 (twenty-five) English articles in (Main) namespace marked for deletion as a whole [6]. I don't see how keeping them together unorganized would make them less useful. Anyone interested in them would specifically search for the name in a search engine.
Why keep pages about dead projects - see my first post above. Besides, this wiki often contains higher quality and quantity documentation than upstream's.
Now, pages which do not contain any meaningful text whatsoever (like Beginners_Guide_to_C++), it's a different matter.
axper (talk) 05:13, 3 August 2014 (UTC)
From Special:Log/delete, we deleted about 300 pages in past 4 months.
Dig through the out of date pages for usefully information is usually harder than starting from scratch because you need to know what is out of dated and what is not.
So in theory, you can re-use these pages. In practic they just pollute "What links here" system. I say this with my KDE wiki contributor hat on which does use Archive namespace for out of date pages.
--Fengchao (talk) 13:29, 9 August 2014 (UTC)
Instead of manually looking for content worth digging out I was/am suggesting to make available/archive everything. Unless, of course, it is spam or nonsense.
It is possible to filter out namespaces in "What links here" pages.
axper (talk) 14:06, 9 August 2014 (UTC)
As I explained below, simple archiving is an inconsistent solution, because when part of an article is removed for some reason (out of date, inaccurate...) it's not archived (though it remains accessible in the history of the article), so there's no reason entire articles should be treated differently. The only solutions that can be considered are those that allow everybody visit the history of "deleted" articles. -- Kynikos (talk) 08:26, 10 August 2014 (UTC)
Ok, I admit I don't have (and probably there can't logically be) any counterarguments against the generic "it might be useful again in the future" argument, and I guess the whole point here is that the deleted content is no longer accessible to regular users, not even in the history of a page, because it seems noone has anything against e.g. removing outdated portions of articles, or removing closed discussions. This means that both deleting and archiving don't comply with the requirements, do we agree on this?
The only solution consistent with all this seems the redirection idea proposed below, but in that case the content of those articles wouldn't appear anymore in any kind of search results, so a user interested in retrieving their content should be aware of the existence of both Deprecated pages and of the old page that redirects there. This would however still sort of answer the problem of possibly breaking external links, as following one would lead to Deprecated pages, which in turn could inform the user on what happened to the article (s)he was looking for.
Considering all this, maybe, and I say maybe, a new policy to address deletions could be to:
  1. Assess if it's possible to redirect the article to another one, as we're already doing.
  2. If not, assess if the history of the page is meaningful enough to justify redirecting the article to Deprecated pages instead.
  3. If not, really delete the article.
The only new step would be 2., which is not so different from 1., so it could even start making sense. This is a very intricate issue, let's see what the comments to this post will be.
-- Kynikos (talk) 11:02, 4 August 2014 (UTC)
What are the security implications of making Special:Undelete available to everyone? See also mw:Help:Undelete. -- Lahwaacz (talk) 11:20, 4 August 2014 (UTC)
That would indeed be a kiss way of solving the problem. I haven't found any discussions about that, and the only bad implication I can think of is if somebody creates a defamatory article and we delete it, we wouldn't be able to prevent anyone from linking to the deleted revision(s) anyway, thus exposing the wiki to possible legal consequences. However, the same attack could be carried out on an already existing useful article, and the same fix could be used in both cases, i.e. using the "change visibility" feature.
Maybe we could ask upstream about other possible consequences.
-- Kynikos (talk) 16:45, 5 August 2014 (UTC)
That is an even better option. axper (talk) 15:21, 8 August 2014 (UTC)
I have sent a mail to the MediaWiki mailing list, let's wait for response... -- Lahwaacz (talk) 09:06, 18 August 2014 (UTC)
Well done, I've subscribed and will step in if necessary. -- Kynikos (talk) 01:46, 20 August 2014 (UTC)
Adding Template:Deletion at the top of a page is a reasonable note/warning in these cases, then the admins can go through Special:WhatLinksHere/Template:Deletion and consider each page. Or is this a general discussion about deletion and archival on this wiki, possibly intended to devise a proper archival solution (e.g. separate namespace)? -- Lahwaacz (talk) 14:59, 2 August 2014 (UTC)
How about making a separate page, Deprecated pages? Any deprecated articles would be blanked, references to them removed, and then redirected to that page. They're "deleted", yet easily accessible via "What links here" should the need arise. -- Alad (talk) 19:28, 2 August 2014 (UTC)
Seems reasonable to me. axper (talk) 05:19, 3 August 2014 (UTC)
Why not just visit Special:Log/delete. Any difference here?--Fengchao (talk) 13:32, 9 August 2014 (UTC)
Well, Special:Log/delete contains (references to) all deleted pages. As Kynikos mentioned, a page like Deprecated pages would only contain articles with notable content in the past, but that is now no longer relevant. -- Alad (talk) 09:07, 10 August 2014 (UTC)
Exactly. The logs are overdose for the intention. I do like the consideration of having a Deprecated pages for singular cases when the admins evaluate a deletion template as well, if that keeps search history neat & up-to-date. I have a limited view on the topic, but it sounds to me that a separate archiving-namespace would be overkill for this.
Imho Karol started this discussion with the best examples for both cases: Ubuntu One wiki information will surely float around the web for very long, there is nothing an Arch wiki article about using it with this distro can add after it was shut down. The Initscripts/rc.conf, however, is Arch's own history. Another one like that: I tried to update the non-resolving package links for Pacbuild to no avail. Probably the fellow who created it (and the article) back in 2006 would not mind it being deleted now. Yet, the wiki might want to care about the Arch legacy to that extend anyhow. A buffer like the idea of Deprecated pages could help out there. It could have simple sections (e.g. separating Arch-specific content and other content considered notable in different categories, etc.). I also could imagine cases where it makes the decision easier for the admins - some content could be deprecated first and deleted after a safeguarding time. --Indigo (talk) 20:20, 11 August 2014 (UTC)
Well, the new "article" would only be used as a redirect target in place of deletions with something like #REDIRECT [[ArchWiki:Deleted]]. Then in it we would instruct users to look at the WhatLinksHere page to see which articles are linked and browse their history. We can't implement anything more complicated than that, i.e. there would be no content to be separated into sections. -- Kynikos (talk) 14:12, 12 August 2014 (UTC)
Ah, thanks for clarifying. Picking up another thought from above not clear to me: Given we cannot distinguish the #REDIRECT [[ArchWiki:Deleted]] from the extensively employed regular redirects to guide to most relevant current content. Might it happen that, e.g. after pursuing that route for a year or two, those redirects start to spoil/pollute search results for the regular user seeking only current content? Or is that not a problem (e.g. due to amount of pages we anticipate to deprecate like that or maybe we can control somewhere that they are only listed at the bottom of search results)? Or is the extra effort small enough to justify testing it out and change route in case it does become a problem (and we might profit from the deprecate-delete decisions already been taken)? --Indigo (talk) 21:39, 12 August 2014 (UTC)
This discussion may be related ... -- Alad (talk) 21:44, 12 August 2014 (UTC)
Well, the content of those "semi-deleted" articles wouldn't be parsed by the search engine, so only their titles could constitute a problem in search results. Now, it's unlikely that titles like "Ubuntu One" could pollute the search results for other still-alive terms, and in case some of them did, that would probably mean that instead of "semi-deleting" them, we should have redirected them to some other related article (see step 1. in the checklist in one of my posts above).
Anyway if this became a problem in the future, all the semi-deleted articles could be quickly and easily finished off with a bot.
-- Kynikos (talk) 01:58, 13 August 2014 (UTC)
@Alad: Yes, it is - ensuring quality of the regular redirects is not spoiled longterm.
@Kynikos: Ok, I take from that the extra redirect can be a worthwhile exercise to try and see. Something that cannot be done with the fourth option without more certainty about consequences.
Re "finished off with a bot": and the tagging as "semi-deleted" could also be useful to recycle the bunch another way (e.g. if route is changed to something else than "delete" for whatever reason).
Now for the fourth identified option to publicize Special:Undelete I wonder about search accuracy as well: would turning it on spoil internal search results? (no) How about external search engines? Any chance those get confused and suddenly index deleted content that they don't crawl now? --Indigo (talk) 20:29, 13 August 2014 (UTC)
You've answered the first question: no.
Second question: to view the content of a deleted revision, a POST request is needed, and that's something that search bots don't do, at least the normal ones. But even if that wasn't the case, history pages, old (not top-level) revisions and deleted revisions (and many other kinds of pages) all have <meta name="robots" content="noindex,nofollow" /> in the head, which allows me to confidently answer "no" as well.
-- Kynikos (talk) 04:31, 14 August 2014 (UTC)
When redirecting the page to Deprecated pages, the operation would be (btw. see the table below for comparison with other solutions):
  1. Update/remove all backlinks (as is done today when deleting a page)
  2. Redirect the page
  3. Protect the archived page to prevent updates
I'm assuming here that the solution should be similar to the current way in that archived pages should not be updated and that archived pages should not be linked. And this is the problem, we can't technically prevent linking to archived pages if we choose this solution.
-- Lahwaacz (talk) 23:16, 13 August 2014 (UTC)
I'm not sure if protection is needed, after all deleted articles can be freely recreated, so semi-deleted articles shouldn't have a higher level of protection.
About links, the fact that the semi-deleted articles are redirects that point to ArchWiki:Deleted should already discourage linking to them. The same goes for any kind of links, we can't technically prevent any kind of nonsensical links, I think that's an unrelated problem. Yes, it's possible that somebody links to an old revision of the semi-deleted article with an external link, but that's already true for the old revisions of the existing articles.
-- Kynikos (talk) 04:31, 14 August 2014 (UTC)
Right, when we provide an archive, it should be possible to link to the archived revisions. Anyway, there could be a difference between redirecting and deleting as it seems that I can't link to specific revision of a deleted article - the preview button from [7] just gives this url: https://wiki.archlinux.org/index.php?title=Special:Undelete&action=submit.
-- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
There is a difference, you can't link to a fully-deleted revision because only its plain source text can be queried normally (mw:API:Deletedrevs and mw:API:Undelete#Token), so the rendered page can only be previewed (I guess with the same algorithm that previews normal pages being edited), which requires a POST request (i.e. no parameters visible in the url => unlinkable). This is another parameter for the table below; I'm not sure if the ideal solution should allow linking or not. -- Kynikos (talk) 14:52, 15 August 2014 (UTC)
About protection, is the ideal solution controlled (i.e. admins (+maintainers?) control which pages will be archived/restored) or open (where anybody can archive/restore a page)? I don't see a problem with controlled as users could ask for the operation to be performed. On the other hand, open archival could bring problems. I think that ideally archival would be controlled and restoration open.
-- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
IMO we should use MediaWiki's default behavior: if we go for the visible deleted revisions, then the archiving operation is a deletion which by default is controlled; if we go the ArchWiki:Deleted way, then the archiving operation is a redirection which would be patrolled just like any other redirection for any other purpose, so it could stay uncontrolled. The same could go for restoration, although if we allow everybody see the source of deleted revisions, it's not necessary to have undelete rights to restore the article, it would be enough to just re-create the article by pasting the source there (I know, it wouldn't be the proper way because all the history would be lost). -- Kynikos (talk) 14:35, 15 August 2014 (UTC)

Why exactly was the "separate namespace" way discarded? Was it FS#35545? -- Lahwaacz (talk) 23:20, 13 August 2014 (UTC)

Apart from 35545, if I understand correctly the "separate namespace" solution would consist in moving the candidate articles into a special namespace without hiding their content with a redirect; yes, all their backlinks would have been cleared, but they would still keep linking to other articles, thus polluting those articles' backlinks, and also some special pages, and that's something that I'd like to avoid. -- Kynikos (talk) 04:31, 14 August 2014 (UTC)

I have modified the row "Permission to perform archiving" for the "ArchWiki:Deleted" way to be simply "editors", which is the least privileged group which could perform archiving under ideal circumstances. There are some cases when editors wouldn't be able to perform the operation by themselves: for example if the archived page had some redirects pointing to it, they should be deleted, because archiving would create a double redirect and "normal" fix would cause the redirects to be archived too, which is useless since there is usually no history.

Also note that archiving would most likely involve more people from different groups: for example everybody could propose a page to be archived, then after reaching a consensus, admins/editors would archive the page, then editors/patrols would check the operation etc. This is not a good material for the table below since it applies to all methods, however it should be discussed because we will have to write guidelines for the archiving anyway.

-- Lahwaacz (talk) 19:53, 16 August 2014 (UTC)

I agree with redirects, they should be deleted when archiving their target, unless for some reason they can be diverted to some other article.
And yes, we should really start writing guidelines not only for archiving, but also for the other common operations (creating/moving/deleting a page, moving a section in the same article or another article, generic redirection...), something like already exists in ArchWiki Translation Team#Create a new page and its translation.
-- Kynikos (talk) 03:36, 17 August 2014 (UTC)
Absolutely, we need to cover that. @Lahwaacz: Also all good with just "editors", but one step we want in the process is the decision about "notable content" in that column, no?. E.g. (1) Karol identifies Ubuntu One as deprecated, (2) ideally proposes a method (redirect or delete) due to content in the template, (3) the delete gets no objections. Now at the latest that "archiving" (deletion in this case) proposal should get to the admins to review/perform. (Just wondering if the simplest would be to use two redirect templates at that point, i.e. "Archwiki:Deleted" and "Archwiki:Obsoleted" or something, but might be totally unnecessary). I must say I am curious what the others think about the current table!? any objections we concentrate on column 3/4? --Indigo (talk) 10:58, 17 August 2014 (UTC)
Yes, the decision step about notability should be in the guidelines.
I'm not sure what you mean about the "Archwiki:Deleted" and "Archwiki:Obsoleted" pages: in case we go for the redirect solution, obsolete pages will be redirected to the dedicated "ArchWiki:..." page if they have a notable history, otherwise they will be normally deleted like we're doing now.
Are 3/4 0-based indices? Just to make it clear, I'd concentrate on the last 2 columns.
-- Kynikos (talk) 01:46, 20 August 2014 (UTC)
When I added above rough idea quoting "Archwiki:Deleted" and "Archwiki:Obsoleted" I was thinking again about the easiest workflow to distinguish the decision to either archive or delete. Sticking to "Ubuntu One": how do you get to know that (1) the deletion proposal had no objections and (2) it's time to delete it.
To my understanding the admins currently either consider a deletion template set by others by running across it, or by getting notified individually. The idea was that using two new redirect templates (deleted/obsoleted) instead of one, the two buckets could be filled - each to be reviewed at its own pace. Clearer? --Indigo (talk) 07:40, 20 August 2014 (UTC)
Then you have used the wrong prefix, you meant "Template:Deleted" and "Template:Obsoleted". There is already Template:Deletion, so I would use "Template:Archival" for the new template. Maybe it would be clearer to use just the verb: "Template:Delete", "Template:Archive", "Template:Move", Template:Merge... -- Lahwaacz (talk) 10:46, 20 August 2014 (UTC)
Uhm, with "two buckets" I actually meant two new redirect targets: one for semi-delete/archive (column 3), one for delete. If the delete-redirect would be set by an editor, the admins only have to check that bucket for new redirects and review/delete those articles. Likewise for the semi-delete/archive (column 3) redirect the notable content decision would be checked.
Using two templates for the distinction instead, you in your admin role still have to track status of the deletion template(s) across the wiki somehow, your fellow admin maybe does it as well, etc. Maybe it is clearer, if you see the two redirect-targets as patrol-points.
Does that make sense/sound practical? (I may well be over-engineering our case:) --Indigo (talk) 14:16, 20 August 2014 (UTC)
I think that you over-complicate things here... Unlike archival, deletion is a core feature of MediaWiki, there is no need to use the redirect-to-some-dummy-page workaround. Using the MediaWiki's feature, deleted pages are just "gone" for the regular users (at least until the fourth/last column is implemented). Obviously the solutions in columns 3 and 4 (redirection and deletion) can't be combined, redirecting a deleted page would make it undeleted.
We are trying to devise a solution for archiving pages, which is not implemented directly in MediaWiki, so let's focus the discussion on this topic. Also, for now I would like to focus on choosing the archiving technique (the technological solution), the guidelines (user interaction, used templates etc.) can be discussed later as this will inevitably depend on the chosen technique.
-- Lahwaacz (talk) 21:28, 20 August 2014 (UTC)
After reading your post again, another idea occurred to me: perhaps you meant the problem of differentiation between deleted and archived pages? This is a problem exclusively for the last method, i.e. archiving by deleting. If we wanted to somehow distinguish archived pages from "normal" deleted pages, it would be likely done by the "Reason for deletion" (see mw:Help:Sysop_deleting_and_undeleting), which would store the information in the Deletion log. We could probably mark the pages with appropriate template before actually deleting it, but using the "Reason for deletion" seems more natural and useful. -- Lahwaacz (talk) 21:49, 20 August 2014 (UTC)
Thanks for taking the time for above too Lahwaacz. Sure, this can wait. To your question: yes, that's what I meant. I'm going to stop about it, but just a tiny example: User:Indigo/Test1. Now for the example the admins would only have to check the backlinks of that redirect, review & delete (with "Reason for deletion" as usual). We could also use such for the last method as well I believe, if at all useful. --Indigo (talk) 19:50, 21 August 2014 (UTC)
We can re-use the advice to fix the link that led the user there in the redirect for simply-archived pages, although it will make sense only for external/full links, as a good admin will have fixed all the internal backlinks before archiving or deleting an article. About your idea in general, we can already check Special:WhatLinksHere/Template:Deletion, there's no need for a "temporary redirect" after the page has been marked for deletion. -- Kynikos (talk) 13:59, 22 August 2014 (UTC)
Ok, no change deemed necessary then. --Indigo (talk) 16:11, 22 August 2014 (UTC)

List of suggested solutions

A table of additional properties to follow the discussion more easily:

Ideal Delete, don't look back
(current method, not a solution)
Separate namespace
Redirect to a page like
Publicize Special:Undelete
Type of archive operation - delete move redirect
(i.e. modify content, then protectquestioned)
Permission to perform archiving ??? admins depends on config editors admins
Permission to undo archiving ??? admins depends on config (?)
(can be forced w/ copy/paste)
editors admins
(can be forced w/ copy/paste)
Page titles show in wiki search results no no yes yes
(if redirects are included)
Page content shows in wiki search results no no yes no no
Page titles/content show in external search results no no yes
(unless disabled
with 1 or 2)
no no
Secure (see discussion) yes yes yes yes ???
(ask upstream)
Pollutes other pages' backlinks and special pages no no yes no no
Can link to archived revisions ??? no yes yes no

Broken redirects

I have written a simple script to list redirects with broken fragments (i.e. when no section with given title is found on the target page). After filtering out some false positives, here is the result. (And because I am incredibly selfish, I have eaten the low-hanging fruit before sharing the rest with others ;) )

As usual, please strike the fixed items off the list. Some things to consider:

  • The section might have been renamed, either to simplify the title, or just to fix capitalization as per Help:Style#Section headings.
  • Or it might have been merged with other, more generic section. Use the most relevant section for the redirect, or just redirect directly to the relevant page.
  • In the worst case, there is no relevant content on the target page. This will probably deserve a separate discussion.

-- Lahwaacz (talk) 20:01, 18 August 2014 (UTC)

Nice script. I fix zh-cn Chinese pages. --Fengchao (talk) 13:25, 19 August 2014 (UTC)
A little tip, check the date when the redirection was made, then check the history of the target page from that date to see what happened to the section. Alternatively, searching for the keywords of the missing section can help. -- Kynikos (talk) 01:21, 20 August 2014 (UTC)

Systemd 216

Systemd 216 was released; let's keep track of articles that may need updating. Of course don't change actual articles until the new version reaches [core]. (Feel free to add to this list)

-- Alad (talk) 00:29, 22 August 2014 (UTC)

Also Xorg#Rootless Xorg (v1.16) and similar? The fix to run more than one rootless X should be included in systemd/logind 216[9]. -- Lahwaacz (talk) 07:59, 22 August 2014 (UTC)

Nautilus got renamed to Gnome Files

Do we want to rename every occurrence of 'nautilus' in Arch wiki or is the redirect enough? -- Karol (talk) 23:49, 21 August 2014 (UTC)

The redirect has only 3 backlinks, 2 of which are talk pages. About normal strings, this should be a comprehensive list, but it seems pretty dangerous to do a blind mass rename with a bot.
Moving this back to the normal requests.
-- Kynikos (talk) 14:06, 22 August 2014 (UTC)

Bot requests

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