ArchWiki talk:Reports

From ArchWiki
Revision as of 08:43, 26 April 2012 by Kynikos (talk | contribs) (→‎XWiimote: rm closed discussion)
Jump to navigation Jump to search

In this page you can list:

  • Edits that a contributor made to the wiki without a proper explanation (that is what the Summary field is for) and whose validity you lack the knowledge to judge by yourself. In this case, please add a link to the edit in question with a brief explanation why you think it should be investigated. Consider contacting the contributor to ask for an explanation, which is often an effective way to solve these issues. Please report the eventual answer (if any) below the initial report. You can also link to a discussion already started in the talk page of the edited article.
  • Links to discussions started in talk pages requesting to add, delete, or modify some content in the respective articles which you do not have sufficient knowledge to answer definitively by yourself.

Please sign your edits and feel free to comment on others' reports. Discussions will be deleted 3 days after closing.

See ArchWiki:Spam to report vandalism.


Softphone should be marked for deletion in coherence with this edit? (with which I agree) -- Kynikos 11:52, 23 May 2011 (EDT)

I don't see ekiga, linphone and twinkle anywhere on the Common Applications page. I would either leave Softphone or merge it with Common Applications although I'm not sure how common those softphone apps are. -- Karol 17:29, 23 May 2011 (EDT)
You're right, those apps can't be called "common"... The fact is that, to me, pages like that look too much like duplicates of Categories, and I don't like duplications... I don't know, maybe this is more a style problem, but at least we could rename pages like that with "List of ..." ("List of softphopne applications" in this case) like Wikipedia does? Or we could add lists with short descriptions directly in Category pages? -- Kynikos 05:13, 24 May 2011 (EDT)
Apart from Skype those apps don't have their own wiki pages in our wiki, so you can't create a category 'Softphone'. Renaming this page to 'List of softphopne applications' looks fine to me but maybe in this case we should tell people to use and ? Or do we allow to create an Arch-centric (i.e. no Windows-only apps) "copy" of those articles? -- Karol 05:40, 24 May 2011 (EDT)
The problem is where exactly would you put the links to the Wikipedia articles? Maybe we could allow the creation of Categories with a few members but containing lists of external references (with short descriptions)? -- Kynikos 05:58, 24 May 2011 (EDT)
I was thinking about something like this: it not only lists the pages in the category, but also provides some additional info at the top of the page. -- Karol 16:30, 3 September 2011 (EDT)
Probably the only problem would be that the search engine doesn't seem to show categories among the results, so the keyword "softphone" would be lost in this case. I would reconsider merging Softphone with Common Applications, and this would also change my mind about its title, List of Applications could be the best solution. -- Kynikos 08:51, 4 September 2011 (EDT)


Somebody with knowledge on the subject should verify this edit. By the way the article should be reorganized, especially in the first part where there is extensive use of sudo; also these edits, immediately following the one reported before, seems not to fit too well in that location, and "-p" should be changed to "-d" I guess... -- Kynikos 08:15, 24 July 2011 (EDT)

I've got another edit that needs to be verified .e.g 'pacman -Sy postgresql' doesn't seem right. -- Karol 17:25, 7 October 2011 (EDT)

Personal articles in the wiki

Is it better suited for a user page? -- Karol 20:29, 14 August 2011 (EDT)

I think he's not using the article for personal notes, he's sharing his knowledge on the matter. However he should be warned to avoid personal statements, probably the title should be changed, he should seriously evaluate the possibility to merge the content with Small Business Server and above all with Small Business Server (Italiano), which has far more content (and its own category), as he can read and write both languages. And then the current category doesn't exist, headings should start from 2nd level and so on :)
Of course this is my idea, if you bring more reasons why it should go to his user page we can discuss further, probably inviting also the author, so he doesn't possibly work for nothing. -- Kynikos 05:54, 15 August 2011 (EDT)
I like your idea, let's invite him to have a look at the existing articles. -- Karol 06:26, 15 August 2011 (EDT)
I'm writing him later, unless you do it first: whoever contacts him, note it down here. -- Kynikos 06:38, 15 August 2011 (EDT)
I've just sent him an email. -- Kynikos 11:39, 15 August 2011 (EDT)
A month later, nothing changed. What do we do? -- Karol 19:37, 15 September 2011 (EDT)
He never replied to my email, at least it needs the Stub template and categorization in Networking, just like Small Business Server. Other that that I don't know atm, it would be a pity to request its deletion, after all it seems to contain useful info, although I haven't checked if it duplicates the content of other articles. -- Kynikos 06:33, 16 September 2011 (EDT)

Software RAID and LVM articles

I have essentially completed my revision of the Installing with Software RAID or LVM article. I moved the new draft in my user space to Software RAID and LVM. I still plan on creating RAID and moving RAID/LVM specific information to their respective articles. Next I would request the deletion of the old Installing with Software RAID or LVM article and place a redirect to Software RAID and LVM. Then place a link to the most recent revision of the old article on the Talk Page of the new one. I would love it if other people could compare the two before I request deletion of the old version. ~ Filam 16:12, 16 September 2011 (EDT)

I haven't checked your work in detail, I don't event have much knowledge of RAID, but it looks good at a glance, although I haven't understood why Software_RAID_and_LVM#Update_RAID_configuration is stricken.
Of course redirecting Installing with Software RAID or LVM to one of the new pages and requesting its deletion are conflicting operations, I suggest choosing to redirect, also to make it possible to link to the old revision.
-- Kynikos 06:40, 17 September 2011 (EDT)
Ah, the strike was formatting left over from when I was drafting the article. I'll remove it now.
Thanks for the explanation. I wasn't clear about the difference between a moved article and a redirect.
~ Filam 10:42, 17 September 2011 (EDT)
I think you can remove the content of the page and leave only the redirect instead of keeping the content because people won't see it anyway - they get redirected to the new article. What about the talk page?
I think redirect pages should have only the redirect, like so. -- Karol 11:15, 17 September 2011 (EDT)
Karol is right, I have removed the content from the redirect page, then I have moved the content of the talk page to the new article's talk page, and then redirected the old talk page to the new one.
Still to do: see if some discussions in Talk:Software RAID and LVM have to be moved to Talk:RAID.
Note for Filam: good job, but next time you should first decide the title of the new page and move the old article to the new page. This, besides automatically redirecting both the article and the talk page, moves also the history of the edits and other possible statistics of the page. Only after doing that you can replace the content of the article with the new draft, and if necessary also split the article.
-- Kynikos 05:40, 18 September 2011 (EDT)
Thanks for the explanation Kynikos. That certainly makes more sense, and thank you for making those changes.
~ Filam 13:31, 18 September 2011 (EDT)
@Filam: since it seems you have good knowledge of the article, can you take a look at Talk:Software RAID and LVM and see if something has to be moved to Talk:RAID? And if some discussion are exhausted or outdated you can also just delete them. -- Kynikos 05:50, 19 September 2011 (EDT)
Kynikos, I saw your previous note and I'll certainly get around to it. [the rest of the reply has been moved to Help_talk:Style#Archive discussions?] -- Kynikos]] -- Filam 21:25, 19 September 2011 (EDT)
Great, thanks ;) -- Kynikos 06:06, 20 September 2011 (EDT)


Many articles have been moved from Category:Emulators to Category:Virtualization: except that the new category lacks the currently standard suffix (disputed), do we really need to distinguish between emulation and virtualization software? Just think that VirtualBox has been kept in both categories, and there's Category:Wine (Wine Is Not an Emulator) that is under Category:Emulators. What about moving everything to something like Category:Virtualization and Emulation?

(I know, this discussion starts within the scope of ArchWiki:Reports and seems to end under ArchWiki:Requests, we can move it there if needed)

-- Kynikos 14:16, 21 September 2011 (EDT)

Related: ArchWiki:Requests#Category Virtualization and Category Emulators (English). -- Kynikos 09:48, 25 September 2011 (EDT)

GNOME edits

Not sure about them. Can anyone have a look if the removed content was really unworthy of our wiki? -- Karol 06:34, 22 September 2011 (EDT)

I really don't know, GNOME would really need a trustworthy GNOME user to do some moderation... -- Kynikos 15:23, 23 September 2011 (EDT)
One thing is sure, having those scripts or not does not make a big difference I guess, maybe if nobody else has better ideas, we could just restore them to drive away any doubts. An alternative is placing them somewhere in GNOME Tips. -- Kynikos 15:36, 23 September 2011 (EDT)
See Talk:GNOME#Cleanup starting (Was: Is this still a gnome wiki?). -- pointone 15:36, 19 January 2012 (EST)


Can someone have a look at some changes starting here? -- Karol 07:56, 27 September 2011 (EDT)


These changes to FVWM should be checked. At least the installation section has been messed up. -- Kynikos 18:04, 10 October 2011 (EDT)

Courier MTA

'# as root' needs to be converted to '#' at the beginning of commands that should be executed as root e.g. change

# as root
mkdir /etc/authlib/userdb


# mkdir /etc/authlib/userdb

Instead of using '#' for comments, those comments should be converted to ordinary wiki text. -- Karol 07:54, 25 October 2011 (EDT)

Not a report but related to reports

I have recently revised my Recent Changes patrolling procedure: I've created User:Kynikos/RC Patrol, where, during my daily patrol, I semi-automatically append the edits that require more than just a quick fix, using a feature of my Wiki Monkey, which allows me to do that with just a click from diff pages :) My idea would be to go through the list when I have more time, like in the weekends.

The main reason for this is that patrolling was taking too much of my wiki time, which I'd instead like to spend more on other kinds of improvements (my todo list is becoming quite long...).

Now the problem is that realistically that list is going to grow more and more, simply because the sum of the time I was spending fixing the recent changes before will never be equal to the time I can spend there on weekends only. That's why I wanted to discuss the idea of creating an ArchWiki:RC Patrol (or similar) page with an analogous structure, which would become a sort of "quick reports" page, without any kind of discussions, as opposed to this page. This may even become a larger project, with which I'd like to try and involve some users in an official Wiki Maintenance Team, with 2 main functions:

  • Better organize and rationalize the maintenance of the wiki, by having some users concentrate more on patrolling (initial reports filter), some others more on fixing (final reports filter), and some others on performing structural improvements (not related to edit reports).
  • Motivate the participating users by making them feel part of an official team, whose help would be more easily recognized and appreciated also by normal users. We could even upload a special image that official maintainers can put on their user page, just like wikipedia:Template:User_wikipedia/RC_Patrol (see also wikipedia:Category:Wikipedian_recent_changes_patrollers). I don't think we can afford monetary retributions at the moment, sorry... XD

Well, this idea is still in an embryonic stage, but if somebody is interested we can try developing it: I'm sure that even 4-5 users would be enough for starting doing things more seriously and efficiently...

Thanks for reading -- Kynikos 18:13, 12 December 2011 (EST)

Would e.g. [1] be considered an 'initial report'? PeterL did an 'ic' template to 'filename' template change (among other things) - needs fixing but not necessarily a discussion. If I have a minute or two, I'd just go through his recent edits, fix them where needed and post to his talk page about our new wiki style. Should I post the link to that diff somewhere (ArchWiki:RC Patrol?), hoping that somebody else will fix it before I get to it? ;P Currently I simply bookmark such edits and go through them if/when I have time and can still see things properly (my eyesight gets blurry a lot). -- Karol 18:39, 12 December 2011 (EST)
The "filtering" process would go something like this (I'd like to make a flowchart for this):
  1. we start with all the recent changes in an interval of time (for example I patrol daily, so for me it's 24h)
  2. patrollers check each edit and decide (subjectively) whether an edit requires a fix or not
  3. if an edit requires a fix, the patroller decides (still subjectively): does it require a quick fix or not?
    • if the edit requires a quick fix he just fixes it
    • else, he adds a link to the diff in the Patrol page
      Note: If the patroller doesn't use my script (or someone else's), the process of adding the diff to the table may be even longer than fixing the edit itself. It's important that this operation can be done with the same speed and ease as bookmarking the page!
  4. here come the "fixers"' duties: they simply ignore the recent changes page (unless one wants to be both a patroller and a fixer, which may be required with just a few users participating...) and start their job from the diff table in the patrol page. They just pick an entry from the table (preferably among the oldest timestamps), read the patroller note to see what he found wrong, and try to fix the edit.
    • if the edit can be fixed without a discussion, he just fixes it and then removes the link from the table
    • else, he still removes the link from the table, but adds it to ArchWiki:Reports and starts discussing it like we've been doing until now
About posting messages to users' talk pages, among my future improvements to my script is the ability to insert, in a talk page editor, some standard messages for common errors, so that they just require some little (if any) adaptations in order to be submitted to the user.
-- Kynikos 05:42, 13 December 2011 (EST)
It would be awesome if we had a coordinated recent changes patrol like this. I think there's a group of maybe 6 people who edit the wiki regularly and might participate (I can probably convince some people on #archlinux-offtopic to join in too). I often find things that need fixing, but I just bookmark them and leave it until later - most of it isn't worth posting on ArchWiki:Reports because the fix is usually obvious but I don't have the time to do it right away.
At the moment I'm wasting all my free time on AI Challenge, but I'll definitely help out with developing the script after the 18th when submissions for that are over :). thestinger 13:49, 13 December 2011 (EST)
Oh man, how much code is wasted on that game... :D It seems you're doing quite well, though!!
About the patrol, I think the first step is creating an official page in the ArchWiki namespace and define the structure and operational rules of the team (and move this discussion there); once that page is ready we can (and probably should) invite some reliable users to participate: of course it's necessary that the members have enough experience in wiki editing, and they should be made aware of the most common problems that are found in the recent changes (and the best ways to fix them) and of Help:Style too. I think that at most 2 or 3 among the most experienced users should patrol the RC, and all the others should concentrate on fixing the reports.
I would go with ArchWiki:Maintenance Team and the table would go under a "Quick reports" section at the bottom of the page.
What about the idea of having each member put a little icon on one's user page?
-- Kynikos 11:37, 14 December 2011 (EST)

Common apps

I'm not sure if I agree with [2] + our App template seem to break the wiki '**' markup . -- Karol 20:40, 13 December 2011 (EST)

About [8] I don't mind one version or the other. About the App template, the problem is easily fixed with a <br>, but the second line will get first-level formatting:
Compare the current App:
  • Firefox — The Firefox Web Browser is the faster, more secure, and fully customizable way to surf the web. || firefox
    • Firefox — The Firefox Web Browser is the faster, more secure, and fully customizable way to surf the web. || firefox
... with the new possible style (implemented in Template:Sandbox/App): (Code: <includeonly>{{{1}}} — {{{2}}}<br>{{{3}}} || {{{4}}}</includeonly>)
Do you like it also with bold links? The alternative is forbidding indented App instances. -- Kynikos 09:30, 14 December 2011 (EST)
I prefer the non-bold links but you're the style guide guru so do as you please :-) The fixed templates look fine otherwise. -- Karol 09:36, 14 December 2011 (EST)
I too prefer the non-bold links, there would actually be a third option that would give us the best of both worlds, but it would require an optional parameter in the template for indented instances, something like:
*{{App|[[Firefox]]|The Firefox Web Browser is the faster, more secure, and fully customizable way to surf the web.||{{Pkg|firefox}}|:}}
(note the colon at the end). Thoughts?
-- Kynikos 09:54, 14 December 2011 (EST)
Can this report be closed? It looks like the template has been fixed and the change in [7] reverted. -- pointone 10:01, 4 April 2012 (EDT)
I still can't properly indent our App templates with '**'. -- Karol 10:41, 4 April 2012 (EDT)
My position about the proposed reform of the template has changed meanwhile, see FS#29021. I know this will cause some complaints, but for coherence I think Template:Sandbox/App is the solution here. There's also the optional-parameter solution, which one do you like? -- Kynikos 06:09, 5 April 2012 (EDT)
Keep it simple -- the current Template:Sandbox/App solution is best. -- pointone 12:57, 5 April 2012 (EDT)
+1 -- Karol 13:01, 5 April 2012 (EDT)
Template:App is updated; I've used <small> to compensate for the links becoming bold, and I happen to like it. Anybody else does? See Common Applications for the major example.
This report will be closed with the deletion of Template:Sandbox/App as soon as we agree on the new style.
-- Kynikos 15:31, 6 April 2012 (EDT)
Update: we have a bug, look at Backup Programs#Backup software. Ideas on how to deal with this? Minor problems also in AUR Helpers. -- Kynikos 15:49, 6 April 2012 (EDT)
Looks ugly and unreadable for me. Are we running out of space on pages? IMHO, multi-level indentation is something contradicting with Template:App's idea: if you want to write something huge and complicated, create new article for it. Also note, that you was able to indent the old version of template with :*{{App... --AlexanderR 15:56, 6 April 2012 (EDT)
Actually, I proposed forbidding indented App instances (09:30, 14 December 2011) and we somehow forgot about that option; we should reconsider it, after all the diff that started this discussion was about the Abiword Light entry, which is now at the same level of Abiword (Common_Applications/Documents#Word_processors) and looks good.
:*{{App... didn't indent the second line, which always started with only one : regardless of the level of indentation of the first line.
-- Kynikos 16:38, 6 April 2012 (EDT)
I've looked in many articles and couldn't find instances of App indented deeper than 1st level, so I've restored its previous state in order to avoid the mentioned bugs; then I've added a rule in Template:App to restrict its usage to first-level lists. -- Kynikos 10:53, 7 April 2012 (EDT)
PS You can easily fix FS#29021 by removing all formatting from all links – I believe this can also fix a lot of hidden and still uncovered bugs related to CSS styling ;) --AlexanderR 15:56, 6 April 2012 (EDT)
Well, the current style for links is part of the ArchLinux skin (preferences->appearance); if we removed bold, visited links would become even more invisible (I know we discussed about making them purple, but wiki bugs are already solved quite slowly, it seems, and I think having too many irons in the fire wouldn't help at all...)
-- Kynikos 16:38, 6 April 2012 (EDT)

Force bold to {{{1}}}?

While we're at it, without starting another discussion, I'd like to force bold on the first argument of Template:App: <includeonly>'''{{{1}}}''' — {{{2}}}<br><small>{{{3}}}</small> || {{{4}}}</includeonly>

This way even the entries whose first argument is not a link (and there are quite a bit, not only in Common Applications) will still be highlighted.

-- Kynikos 15:36, 6 April 2012 (EDT)

+1, consistency is always nice :). thestinger 00:35, 11 April 2012 (EDT)
Implemented, it gives a definition-list-like effect, I like it especially in entries with long (multiline) descriptions, let's see if it receives other positive or negative feedbacks. -- Kynikos 08:22, 11 April 2012 (EDT)
One positive feedback coming up: I like it :-) -- Karol 17:23, 17 April 2012 (EDT)
Well, 3 + and no - is enough to close this whole discussion (the first part has resulted in forbidding deeply-indented App entries as no solution is possible without causing worse bugs). -- Kynikos 06:19, 18 April 2012 (EDT)

New templates

Just a heads-up, if you're OK with them [3] [4] , please close the report :-) -- Karol 07:42, 14 December 2011 (EST)

If we start applying them consistently in all the tables, probably adding a proper rule in Help:Style, then I'm ok with them, since coloring cells in tables is not very straightforward even with wiki syntax.
Note their Chinese counterparts have been created too: Template:是 and Template:否. Since those templates' code is very flexible, I suggest replacing them with only 2 templates, Template:Y and Template:N, which would produce "Yes" and "No" by default, but whose first optional argument would allow them to display any other string, including translations, without the need to have localized versions of each template.
Going even a bit further, since some tables use additional colors, we may base the templates' names on their color instead of their meaning, so that we would have Template:G, Template:R, Template:Y, Template:B, and if necessary also Template:P and Template:O (purple and orange, just to complete the secondary colors). These templates should require the first argument, but I think they would be easy to use anyway, for sure much easier than the current | style="color:...." | blabla.
Waiting for opinions. -- Kynikos 09:19, 15 December 2011 (EST)
This template group would also give us an excuse to delete The Status Table Series and related templates, since they have a too narrow field of application and practically just create nested tables in the end, thus giving almost no real advantage. -- Kynikos 13:13, 24 December 2011 (EST)
I support this idea. Similar to the Template:Box COLOUR templates, a series of table cell coloured templates would ensure consistency across articles. -- pointone 16:46, 19 January 2012 (EST)
So good :) However I don't consider this an urgent task, I'm linking this discussion from a new entry among my numerous template ideas in my todo list. Of course if you or someone else want to implement it, just go for it. Just reminding that the implementation should be accompanied by some related style rules.
Also note that among my template-related ideas there's one about the Box COLOR series that seems to go in the opposite direction than the cell color templates, but I think that the colors for the Note, Warning and Tip templates should be reserved for them, and not be usable in other ways.
-- Kynikos 06:47, 20 January 2012 (EST)

System recovery category

This edit adds some information to a category page, and it definitely doesn't belong there. I'm not sure what to do about it though. thestinger 17:06, 6 January 2012 (EST)

I decided to move the information to General Troubleshooting but it needs some work. thestinger 17:11, 6 January 2012 (EST)
Not a bad idea moving it there indeed. What about merging General Troubleshooting and Step By Step Debugging Guide now? And leave the merged article in Category:System administration only? -- Kynikos 07:29, 7 January 2012 (EST)
I'm not sure if we should merge them. I think adding a merge tag to the articles (we should really have the "merge to" and "merge from" templates like Wikipedia) and getting some more input would be the way to go. thestinger 13:08, 8 January 2012 (EST)
Ok, we can wait for more opinions :) Also this very report can be enough at the moment. I'm adding the Merge to/from idea to my todo list among the many others, of course if you want to implement it just go for it. -- Kynikos 09:02, 9 January 2012 (EST)
I vote for merging both into a Troubleshooting or Debugging article. -- pointone 09:55, 4 April 2012 (EDT)
My preferences: General Troubleshooting > Troubleshooting > Debugging > Step By Step Debugging Guide.
(BTW, for casual readers, the merge to/from idea was discarded in another discussion).
-- Kynikos 08:30, 5 April 2012 (EDT)
Related forum thread. -- Kynikos 11:59, 7 April 2012 (EDT)

New dependencies for pacman

Some parts of the wiki may need updating, e.g. [5] (the last one in the faq). -- Karol 08:39, 20 January 2012 (EST)

This sounds more like a request, I'd move it under Requests#pacman_4_in_.5Bcore.5D, as a subdiscussion, agreed? -- Kynikos 07:57, 21 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)

Pacman Rosetta

[6] No idea what eix -i does, but pacman -Qs doesn't search inside packages. Asked for clarification on authors' talk page. -- Karol 07:57, 26 January 2012 (EST)

Probably should read "within [the subset of] [locally] installed packages." I think this page could use some clean-up -- the section headings within the chart are not visible enough. Commands could be better organized. -- pointone 13:21, 28 January 2012 (EST)

Arch Translation Day

What about Arch Translation Day and the call for French translators? Should we better specify that they should contribute to ? -- Kynikos 08:49, 28 January 2012 (EST)

Started a discussion in Talk:Arch Translation Day. -- Kynikos 09:05, 28 January 2012 (EST)

Categories and event articles

On January 26 and 27 (CET, also 25 or 28 may be included in different timezones) User:Trontonic (TU) has uncategorized some event-related articles, or moved their categories at the bottom of the pages. See Special:Contributions/Trontonic. -- Kynikos 05:37, 31 January 2012 (EST)

A friendly reminder about Help:Style on User talk:Trontonic -- specifically mentioning category placement and avoidance of uncategorized articles -- is probably the best course of action. -- pointone 10:36, 16 February 2012 (EST)
Notice given. Still need to re-position categories in some pages. -- pointone 09:49, 4 April 2012 (EDT)
Uh thank you pointone, I managed to forget this one ^^' -- Kynikos 05:59, 5 April 2012 (EDT)

Setting up multiple network interfaces in rc.conf

AskApache did some rc.conf article cleanup but he removed the mention of netcfg. I pointed this out on his talk page. I'm not sure if he's done with the rewrite, so I'm not going to jump in and add it myself just yet.

Even if the user creates all the profiles and adds net-profiles to the daemons, his network won't work, because he needs netcfg package - which is not obvious from the current version of rc.conf article. -- Karol 05:29, 26 February 2012 (EST)

Thanks for noticing that, I finished the edits to that page and placed a link to netcfg, but you may want to make sure it is obvious for people that they need that package AskApache 05:47, 26 February 2012 (EST)
I'm not sure the multiple Interface section should be in rc.conf at all. If anything's missing from netcfg configuration article, it should be added there.
DAEMONS=(@syslog-ng !network net-profiles crond sshd) from the daemons section is important enough to explicitely mention it: I think you have to disable network daemon if you want to use net-profiles, right? -- Karol 06:11, 26 February 2012 (EST)
The way I have always used the Rc.conf page is when I'm setting up a new install of arch I go through it. It used to be quite simple to setup multiple interfaces right from rc.conf for several years, but now that netcfg is required it means when I perform a new install I have to view 2 pages to get it. That's why I like it there. I do agree that the page shouldn't get cluttered with custom setups, (I left out wireless configs for example). But OTOH, the netcfg page is fairly large and complicated for new netcfg users. It actually only takes a minute or 2 to setup multiple interfaces if you have that code to cut-and-paste, otherwise you have to go searching the netcfg page and Configuring Network page. I added all the info to rc.conf that I would personally want the next time I am installing a new arch to save time and adhere to the historical use of rc.conf being the only thing needed to get running. Now that I know I won't be installing again for awhile, it wouldn't affect me to remove that section, but I think it makes a quick setup easier for new-to-arch users, especially since the rc.conf is an archlinux-specific feature.
Disabling the network daemon is not neccessary because it's only started explicitly. The network daemon is essentially the netcfg script built for 1 interface without as many user-definable options. --AskApache 18:26, 26 February 2012 (EST)
I've read that you should DAEMONS=(... net-profiles ...) #replace network [7], I've seen the warning and the daemons array here, and here and they all say you should keep just one daemon. If it's not true for netcfg, this should be noted somewhere and the daemons section should use another daemon to show blacklisting with '!' because it gives the wrong impression (it comes just after the networking section). -- Karol 19:17, 26 February 2012 (EST)

Duplicate content

Reminder: same script added in Boot Debugging and Kernel modules, see User_talk:AskApache#Duplicate_content. -- Kynikos 08:33, 27 February 2012 (EST)

Archlinux Turkiye Documentation

Reminder: sent an email to User:Tarakbumba asking more information about the exact meaning and implications of Template:Mark to delete (Türkçe). -- Kynikos 06:29, 2 April 2012 (EDT)

Ok, the meaning is now explained in Help talk:I18n#Turkish Wiki Pages moving to Archlinux Turkiye site ( and ArchWiki Translation Team (Türkçe). This report will become a request when we'll have to delete the Turkish articles. -- Kynikos 13:22, 2 April 2012 (EDT)

Java SE 6

A new page was created with instructions on Java 6, but it could be a lot simpler due to the existence of jre6AUR and jre6-compatAUR (is jre7-compatAUR needed too?). thestinger 00:43, 11 April 2012 (EDT)

The author should probably be contacted, it's his first contribution, maybe he's just inexperienced? Alternatively he may have indeed some reasons not to use the AUR packages?
In any case he edited also Java, so if we delete/modify the page we should take those modifications into account.
-- Kynikos 08:06, 11 April 2012 (EDT)

btrfs stable?

Some days ago User:Graysky edited btrfs as it had been declared stable: whole history, in particular [8] and [9]; see also [10] and Talk:Btrfs#Troubleshooting is now outdated. Then, User:MajorTom has disputed those changes with [11], and I somewhat agree, as I've not been able to find any official statement about btrfs being declared stable. I'm contacting Graysky. -- Kynikos 17:22, 14 April 2012 (EDT)

Guys-I based my statement on the fact the oracle released this in ol6 and back ported it to ol5. Couple that with some emails from Avi miller and there you have it. Graysky 17:52, 14 April 2012 (EDT)
I know that btrfs' wiki isn't really up to date, but we're clearly colliding with [12], so I think, in order not to confuse Linux users (as our wiki usually ranks quite high in many google searches), you should undo MajorTom's edit and add some reference links to support the points in Btrfs#Recent Developments as he requested; can you do it? Thanks ^^ -- Kynikos 18:45, 14 April 2012 (EDT)

Another pacman tip using awk instead of expac

This script doesn't seem to work, maybe expac "%n %v %m" -Q would be better. contacted the author .-- Karol 10:27, 18 April 2012 (EDT)

Let's try again: I meant this edit by TuxLyn. -- Karol 10:56, 18 April 2012 (EDT)