Those are seperate things.
You already get how to compile it and such.
Creating a pkgbuild is how you would make it into a package for use with pacman.
Those are seperate things.
Oh lawrt, yes, it seems that I have to edit the PKGBUILD by hand and somehow learn the scripting for it. Ouch. It seems like a really big extra step, however, also very powerful. A lot of room for error though. :-/
You are free to skip that step so long as you dont want to share it, and keep in mind that it is not recognized by pacman or mhwd etc. then you can just go ahead with doing it manually.
(as outlined in the first link above)
Oh wowww. So if I use that process, and I edit that file, my Kernel will get shared automatically?
That's actually incredibly cool. The trouble is, I'm compiling it specifically for my hardware so how does that work?
Not automatically ... think of it sort of like creating a .deb
You could always share it directly with other or even upload it to the aur.
But if it is super-specific to your own rig that probably isnt necessary in this case.
Anyways that is best left until you are comfortable with how that all works.
Of course you could just be using it for yourself - to better keep track of and such.
But none of those things are required if you just want to compile and run your own kernel. Review the process at the wiki.
@joelf: Hi there. I'm the lead-developer and kernel maintainer of Manjaro Linux. If you have any questions, just ask. As @cscs already pointed out, we are using the application makepkg and PKGBUILD scripts to define on how we compile a package out of source files. This gives you the advantage to create something reproducable and maintainable by a package manager we call pacman. The scripts and additional patches from our end can be found here:
Let me give you a brief walkthru on the files you may find there.
- files ending with
.patchshould be clear. These are adjustments we think will fit for our distro best.
- files starting with
configare our modified settings on how we configure the kernel on our end.
- files starting with
linuxare specific files to post configure the system. They are used either by pacman or mkinitcpio, which configures the initramfs image.
- files ending with
.hookare used by pacman to pre- or post-configure the kernel.
So what does this leave you with? First: with a lot of new questions But - don't worry at all. Depending on your personal issue you are currently willing to change some on the configuration of the kernel. This is a good start.
So here is a quick tutorial to compile your own kernel on Manjaro:
- first you have to clone our package repo for linux417 via
git clone https://gitlab.manjaro.org/packages/core/linux417.git
- then change into that directory and execute
makepkg -s. This will compile the kernel as I had configured it. You may want to stop the time.
- If you however want to use our tools, you may install manjaro-tools-pkg and only change into the directory where you cloned the git-repo. No need to change into the linux417 folder. You simply may use then buildpkg -p linux417. This will create a new chroot on which the package gets compiled in a separate system to avoid any issues with other systems. Only used if you want to redistribute your package to somebody else.
This out, you know now how long it may take to compile the given kernel. To modify, you only have to change or add any file and configure the PKGBUILD file accordingly. Itself is a simple bash-like script file, much easier to understand as the process Debian uses. You may get nuts when reading all the config files of linux417-deb.
Anyway, hope this helps you more and have fun with it. @cscs: thx for pointing out all the basic tutorials on packaging for Arch/Manjaro.
The current Mainline Kernel is v4.18 series. This I'm already distributing, however not all extramodules existing yet ...
I guess you may be interested in looking at the makepkg configuration located at
/etc/makepkg.conf , for example for setting
march=native instead of
generic, you can also make a of makepkg.conf, modify it and pass it to makepkg with an option
What is Aura?
That's excellent information! Ok, I will study up on it. Yes, Manjaro has much more powerful features. It gives us a lot more rope- but more to hang myself. lol!
Do we have anything like Debian's Checkinstall where it fills in the PKGBUILD blanks for us? Checkinstall will create the package and ask the user to fill in some blanks but it automates everything except for Kernel dev.
If I had a Kernel that would work well for the community, how do we share that? I think my Kernels are pretty solid. I would raise the security a little and add more device drivers.
Sounds like you could sell refrigerators in Antarctica, too.
It looks like you're "mixing metaphors" here.
make triggers a step (or steps) in the process as defined in the Makefile, and that may or may not involve creating a package file at the end of it (as with bindeb-pkg).
Just as the
debian directory contains packaging information for Debian packages, the PKGBUILD file contains packaging information for Arch packages. PKGBUILD files are very similar to SlackBuild files and RPM Spec files.
The PKGBUILD file is a Bash script, similar to
debian/rules, but containing all of the rest of the package information which would be held in e.g.
Other scripts and hooks can be defined, as Phil has already said, which can assist in packaging (roughly equivalent to preinst, postint, prerm and postrm scripts).
(The outline approach I would use would be to take an existing kernel PKGBUILD file, generate and save a kernel config, and refer to the generated config in the PKGBUILD file.)
No no, I understand that. You cannot use checkinstall for the Kernel. For that, we have bindeb-pkg. The bindeb-pkg is a new thing, I might add. I've been compiling my Kernel since the 1990s. The first was in 1998, I think. I optimized for my old Pentium and I swear the PC seemed like a whole new computer. Today, it's harder to really notice the difference.
I'll start with what you said. "(The outline approach I would use would be to take an existing kernel PKGBUILD file, generate and save a kernel config, and refer to the generated config in the PKGBUILD file.)" I assume the PKGBUILD goes within the /source/linux-4.17.4 directory but I'll read up on it first.
If I can actually pull this off, I will make a howto on my blog so folks can find it somewhere. I Googled this question and got either wrong answers or really complicated/incomplete answers. You all have provided the best answers so far.
It is possible to take an AUR package https://aur.archlinux.org/packages/linux-mainline/
git clone https://aur.archlinux.org/linux-mainline.git cd linux-mainline nano PKGBUILD
# load configuration # Configure the kernel. Replace the line below with one of your choice. #make menuconfig # CLI menu for configuration #make nconfig # new CLI menu for configuration #make xconfig # X-based configuration #make oldconfig # using old config from previous kernel version make olddefconfig # ... or manually edit .config
Now if you uncomment
make xconfig (I prefer nconfig and know it works there) you can load your custom config and save it as .config.
Next time you can uncomment
make oldconfig if you don't want to change anything.
You probably have to comment
make olddefconfig, def probably means default, I don't know what it is for.
To build and install the package run
makepkg -sri from linux-mainline folder.
PS: To update the package
cd linux-mainline mv PKGBUILD PKGBUILD.my git pull origin master
Great idea! I think the PKGBUILD file that I found was too complicated and I fear that I'll mess it up. I'll try that one right now. I don't use CCACHE since I have the Ryzen 8/16 core. I did add -march=native to makepkg.conf almost immediately upon installing Manjaro- I have to pay myself on the back for finding that. I added also -J14 to use 14 of the 16 threads.
I did not know about the makepkg -sri though. Thank you!
- -s install missing dependency with pacman
- -r remove unused makedepends after
- -i install the created package with pacman
olddefconfig uses default values for new parameters rather than prompting for a value. This is useful when trying to move an existing .config to a new kernel series, which usually has many new options.
I have my old working .config file from the Debian-based system. When I start the .config from scratch, which sometimes happens when the Kernel gets many more new updates or I futz the old one up, I use make oldconfig, plug all my devices in, make localmodconfig, then make xconfig.
I got really close! I copied and pasted my .config file into CONFIG- which the two files looked pretty much the same except for my changes- and it failed. That's the only issue it had so whatever is wrong with the CONFIG file is all I have to fix.
updpkgsums from terminal in the same folder of the PKGBUILD for updating file hashes
Also read the Arch wiki which provide more information than you can shake a stick at, e.g.: https://wiki.archlinux.org/index.php/PKGBUILD