From ArchWiki
Revision as of 01:48, 21 February 2012 by Fengchao (talk | contribs) (Merge Talk:Kernel Compilation)
Jump to navigation Jump to search

Rename to AUR kernels

I'd suggest to rename this page to "AUR_Kernels", updating the list (and dropping the core kernel26 entry, that anybody has installed anyway). The descriptions will need to be extended, though.

The AUR list as of 2008-04-18:

The Linux Kernel and modules with gentoo-sources patchset and tuxonice support
OpenVZ enabled Linux Kernel and modules
The Linux Kernel and modules with Xen support
The Linux Kernel and modules with fbcondecor support
The Linux Kernel and modules, with the grsecurity patchset.
The Linux Kernel and modules with Ingo Molnar's Realtime Preemption patch (see Kernel_Patches_and_Patchsets#-rt). Useful (or needed) when doing audio editing (esp. with jack-related apps).
The Linux Kernel and modules, with IBM Thinkpad specifc patches.
Linux Kernel and modules for Thinkpad
Kernel supporting all important IBM/Lenovo Thinkpad features and providing tuxonice
kernel + tuxonice patchset
Linux Kernel and modules
and featureful Linux Kernel and modules based on linux-2.6 GIT tree

Multiple wiki pages

Why do we have so many different "compile kernel" pages? Obviously there are several different methods that parallel each other in places. For a new[er] user like myself, I found this all confusing. I finally did it the "traditional" way from my home directory. I've noticed no one page is dedicated to a single method.

  1. Kernel_Compilation
  2. Kernel_Compilation_without_ABS
  3. Kernel_Compilation_without_ABS_for_New_Users

I propose there be one page for "traditional from /home and /usr/src" and one for ABS/scripts/automation. With one titled "Kernel Compilation - Automated" and "Kernel Compilation - Traditional". The default search would go to Automated first with a link to Traditional in the intro. New users would be considered in both articles. Pros and Cons should be enumerated for each article as well. T1nk3r3r 14:51, 11 November 2011 (EST)

Done. Main article merged to kernels with links to sub pages. Fengchao 04:38, 18 February 2012 (EST)

A single kernel compilation page

See ArchWiki:Reports#Restructuring of the Kernel Compilation pages (again) for details/rationale. thestinger 23:59, 16 November 2011 (EST)

Good job thestinger! -- Kynikos 09:14, 17 November 2011 (EST)

old talk from Talk:Kernel Compilation without ABS for New Users

I fail to see the usefulness of the script. It does nothing a PKGBUILD doesn't do better and it installs the kernel without integration into pacman. I suggest we get rid of it. Oal

I completely agree. I think it's extremely misleading and we shouldn't encourage this kind of thing. Note that this is mutually exclusive from discouraging someone from building their own kernel outside the confines of makepkg (which we should not actively discourage). Everything about this script scares me, and it leads to bbs posts such as [1] where the user clearly is at a loss because of some unofficial black box involvement. Falconindy
And I deleted this on 8/16. Falconindy
And it's back. -- Karol 06:49, 17 August 2011 (EDT)
Oal / Falconindy, the script is indeed a very useful one and allows any user to upgrade their kernel to any version with ease and simplicity. It runs very well, and has more than adequate checks as to avoid adding/removing any file on a user's system. It also provides a complete summary at the end. I've gotten numerous responses from individuals who were very satisfied using this script, and the statistics alone verify its popularity. Keep in mind, I clearly stated on the wiki it is an "alternative" method to using pkgbuild, and I even provide a link to the package method on the wiki. Nobody is forcing anyone to use the script, it is entirely the user's choice. That user who had an issue could have easily contacted me about the indicated problem (my name and e-mail on the downloadable script is clearly there, and I also encourage anyone with an issue to contact me: that particular user didn't). However, a single issue is certainly no reason to remove such a useful and popular item from the Arch wiki without bothering to contact me at all. I would never in my lifetime remove a helpful and informative wiki submission without first contacting the originating author, it's not standard procedure and a bit unprofessional. This decision of yours seems to be more politically motivated and coincides with a 'heated' debate I recently had on the Arch Linux IRC channel (one day prior to removal of this script) about the method involved with a 'trusted user', which several of you are. After this debate on the #archlinux-offtopic channel, this wiki submission was immediately removed. Strange, isn't it? The individual was a 'trusted user' as well. It seems it is stepping on the wrong toes politically. This is something that obviously works well, and it is being removed. This doesn't seem right at all. I've never had any complaints about the script except for the forum topic you indicated with link. I think we should all discuss this 'live' on IRC at a mutual time. Let me know. This is the most professional way to resolve any issue, instead of blindly removing something because it is deemed to be "controversial". Can you please further explain, in detail, as to why it is controversial?
Karol, and what is your issue with this? You only sarcastically stated, "And it's back". Can you please provide valid and intuitive reasons as to why you might oppose it?
I'm always open and available for constructive discussion. If in the event I do not have time, I always tend to 'make' time. Please provide me with a mutually convenient time and date to meet "live" on either chat, or even Skype if you prefer. Let's discuss this in person (live), as it is more of an effective means to get things done.
Arch Linux and the community has always been open to alternative, secure, and flexible methods of accomplishing the same function or task, even if the pkgbuild using pacman is the standard. It is completely understandable if a substantial number of individuals had an issue with the Kernel compilation script in question, however, this is NOT obviously the case. I would be glad to hear more of your suggestions as to why this component of the wiki should, (in your opinion) be removed. Again, it's user's choice, and not an enforced standard.
My e-mail is: and nick on IRC 'Losowski' -- Ejmarkow 14:48, 17 August 2011 (CET)
I didn't mean to be sarcastic, only to be brief. I marked the issue as closed so I thought I should point out that it's not solved at all. -- Karol 11:45, 17 August 2011 (EDT)
The script isn't useful (if you want automation, use a pkgbuild) and is controversial. It doesn't belong here and was therefore removed. If you want to keep it in the wiki, I suggest you move it to its own page (suitably labeled controversial). Frankly, your undoing the removal is unprofessional and possibly the start of an edit war. — yngwin 12:31, 17 August 2011 (EDT)
@Yngwin, when it comes to installing the Linux Kernel, as you know being a package maintainer, there are several options to achieve this. Use the pkgbuild, or opting not to use it, or use pacman to install a pre-configured vanilla 'stable' kernel. The script in question only automates the manual compilation process which is quite basic for anyone with knowledge of it. It wasn't meant to automate or replace the pkgbuild process at all, it's an alternative (this was made clear in the wiki), never claiming to be better than pkgbuild in any way. Prior to posting a link to the script, I've carefully read all of the Arch Wiki policies and procedures regarding editing and external links and it appeared there was no conflict. The link is relevant to the process I describe. If I were to come across a wiki entry (that goes for any wiki) and feel the need to 'remove' a segment in its entirety, it's only appropriate etiquette to, at a minimum, contact the original author first, discuss it, and then come to a conclusion. That doesn't require much effort, does it? It's quite interesting this "suddenly" became such a heated issue, when so many users have been using the script with excellent results for quite a time. Again, the positive and encouraging statistics, lack of complaints, and consistent usage of the script speaks for itself. If the general consensus among the majority of the Arch developers is to remove it, than I shall do so promptly. First, let's discuss it a bit. It would have been informative if such an external link policy was included in the wiki help section in the first place to avoid such matters. Again, no one ever explicitly explained what is so controversial about the script. Sure, it runs in root, isn't in github (yet). What else? -- Ejmarkow 20:47, 17 August 2011 (CET)
@Faclonindy wrote: "Everything about this script scares me, and it leads to bbs posts such as [2] where the user clearly is at a loss because of some unofficial black box involvement." Falconindy, I just received the user's kernel .config file via private e-mail this morning and the problem is a simple input error by the user, and not some "black box involvement" as you wrongly assume. You have obviously exaggerated and compounded a minor issue into something major, which it apparently isn't. The problem and resolution to that user's issue is an easy one: One, single variable value in the script input area was entered incorrectly by the user, which should have matched another parameter in his .config file, and that's all it is. [It has always been clearly noted in the script to ensure both values match]. However, as with any program / script, some things can be improved, such as adding a check mechanism to ensure such a variable mismatch never occurs in the future. If this does occur, a friendly warning message will be displayed along with the error, and the script will terminate. This will be added immediately. Please look at the thread again for my replies. I always make sure to help any Arch Linux user resolve their issues as much as possible. Thank you. -- Ejmarkow 10:01, 18 August 2011 (CET)

FYI, I think Thestinger's recent edit of this wiki page is a very acceptable, descriptive one. A more detailed 'note' along with appropriate links were added as followed: "Compiling as non-root using the Arch Build System is safer than using root and will result in a package that can be tracked by pacman. See Kernel Compilation for details". Also, the wiki page name was edited from "Kernel Compilation from Source for New Users" to "Kernel Compilation without ABS for New Users". This is very good, much appreciated. -- Ejmarkow 22:01, 18 August 2011 (CET)

I agree! Thanks, thestinger, for cleaning this up! -- pointone 19:44, 18 August 2011 (EDT)
I concur with the removal of the script method. @Ejmarkow: Other than patching a kernel, what does the script do? Perhaps re-labeling "Patching a kernel via script" T1nk3r3r 10:41, 8 November 2011 (EST)

Kernel Script / Wiki Page Title / Merging

Note: ejmarkow and I discussed this on IRC - see ArchWiki:Reports#Restructuring of the Kernel Compilation pages (again) for the continuation of this discussion thestinger 13:01, 14 November 2011 (EST)

I don't believe this is a suitable place to compile the kernel for a *new user*. I have successfully (and unsuccessfully) compiled kernels from /home/~ without issue. In fact I would seriously consider merging this article with the other one: Adding notes for new users to consider. The alternate article is the one I used to compile *my* first kernel, and it went off without a hitch. T1nk3r3r 10:41, 8 November 2011 (EST)

You're right, and I've changed the title of the page to match the content better.
Using the existing linux PKGBUILD is without a doubt the best way to do it and is very easy. You really only have to deal with picking the configuration options. These instructions seem a lot harder to follow than both the ABS and the "traditional" way, with the only real difference being that you don't end up with a package and you have to run the commands and compilation as root. Using a release candidate instead of the stable branch that Arch packages have been tested with also seems like a bad idea for a new user.
Useful information in the second part of the article (manual instructions) should be merged into Kernel Compilation without ABS. I think the consensus is that the automated script here duplicates the work of the PKGBUILD (and doesn't make a package), so I think it should be moved to User:Ejmarkow's namespace.
Other opinions are welcome :). thestinger 15:30, 11 November 2011 (EST)

It is unacceptable and without etiquette to alter the main title of any wiki page without first discussing it and coming to a conclusion. You decided to totally bypass this procedure. This is the second time you have done so without prior discussion. This move is without merit and is only being done for your own personal reasons, and not for the benefit of users who wish, by choice, to use an alternative method for compiling the Linux Kernel. As you know, Any working directory besides /usr/src can be chosen to compile the kernel. Hence, your description indicating " /usr/src" is unjustifiable. The wiki page will be moved back to it's previous title and THEN we should discuss it. I believe this is a suitable place for a *new user*, your arguments do not present a valid reason. What I do agree with is merging the 'manual' procedures (bottom half) of the wiki page in question and leaving the top (automated script portion) intact and as is. @T1nk3r3r asked, "Other than patching a kernel, what does the script do?" Please read all comments in this discussion and the wiki page in question, it's self explanatory. The instructions are *not* hard to follow at all. Is changing the value of 5 variables difficult for you, and then running a script? Your analysis is without justification. I suggest (as I have previously) we discuss this live, and log the entire discussion. @Thestinger often sees me on the #archlinux channels, and yet, never discussed his opinion or intentions (not once) in changing anything on this wiki. I find this quite strange. There is nothing more valuable than open discussion prior to making abrupt changes in a popular and valuable wiki page. Again, Arch Linux stands for flexibility and allowing the user to customize any process as they wish to do. It's about choice, using any proven alternative method that works. You are apparently attempting to abolish such freedoms. Again, I await a set place and time for a live discussion, something some of you are trying to avoid. My nick on #archlinux is "Losowski". Thank you. ejmarkow 11:00, 14 November 2011 (CET)

In summary, I suggest:

(1) We keep intact the script portion in a wiki page entitled, "Kernel Compilation without ABS - Alternative Method" or "Kernel Compilation without ABS - Alternative Script Method"

(2) Merge the botton second half (the manual process) with another wiki page, if you wish.

Keep in mind, I'm always willing to add new featuers to the script, and many are planned in addition to what it already has. Some users even suggested a GUI (which I can easily program), however, the GUI seems like overkill. ejmarkow 12:04, 14 November 2011 (CET)

Obviously there are different kinds of *New Users*. I won't go into that now. However, concerning the content of the page: I agree that the second half of the article be merged to the other page. T1nk3r3r 19:07, 16 November 2011 (EST)


"Patches and Patchsets" and "Kernel compilation" is added. So this page become a more general kernel info page. Fengchao 04:48, 18 February 2012 (EST)

I don't think the merge from Kernel Compilation can be considered complete, in fact IMHO now the article should get a new title (just Kernel??) and the introduction should be adjusted. Also Kernel Compilation's subpages should be moved to the new title, and Talk:Kernel Compilation should be merged here.
However I don't know if it was better having two separate articles as it was before (in this case also remember to undo [3] and [4]). Please share your opinions.
-- Kynikos 16:50, 20 February 2012 (EST)

What is "Long" in the Arch world?

I suggest that some description of what "Long" means in the Arch world. A user can't make an informed decision as to the usefulness of an LTS package without knowing its projected lifespan. MichaelRpdx 10:32, 19 February 2012 (EST)

It depends on upstream. thestinger 20:18, 19 February 2012 (EST)
A thread on our ML regarding the new LTS kernel. -- Karol 20:49, 19 February 2012 (EST)