Package Details: linux-lts414 4.14.290-1

Git Clone URL: https://aur.archlinux.org/linux-lts414.git (read-only, click to copy)
Package Base: linux-lts414
Description: The Linux-lts414 kernel and modules
Upstream URL: https://www.kernel.org/
Licenses: GPL2
Submitter: severach
Maintainer: severach
Last Packager: severach
Votes: 8
Popularity: 0.000000
First Submitted: 2019-01-01 20:55 (UTC)
Last Updated: 2022-08-03 16:22 (UTC)

Latest Comments

ReDemoNBR commented on 2022-04-19 21:22 (UTC)

Forgot to update the checksums for the patch-4.14.275.xz source. Here they are for your convenience:

  • md5sum: d3d0e1a2a504d9f411ed0688240f1ade
  • sha256sum: 50da7207d314b8668259433738accbcd85046d7fa452302b229298e4ad45a4d5

jonathon commented on 2022-01-21 20:54 (UTC)

I've packaged up linux-firmware-uncompressed for kernels affected by module compression in linux-firmware 20220119.0c6a7b3-2.

severach commented on 2021-02-09 22:54 (UTC)

Downgrade to binutils 2.35.1-1 to build.

eschwartz commented on 2021-01-03 01:11 (UTC)

Unless you provide the same uname -r and /lib/modules/${_kernver}/ directory (protip: you don't, this is based on _kernelname=${pkgbase#linux}) you do not provide the right interface to support modules compiled for core/linux... NOT EVEN modules compiled for core/linux 4.14.x from way back in 2018.

Now, you were warned by both me and Scimmia, which is twice the warnings you had a right to receive, but I am a gracious person... the next step is I'm going to delete this package if you do anything other than remove the provides. I am speaking with my TU hat on -- I will not listen to further arguments, and you will not get another warning.

severach commented on 2021-01-02 07:03 (UTC) (edited on 2021-01-02 09:49 (UTC) by severach)

It's not broken so it won't be fixed. Arch is a source distro so you are wrong, provides is right. Nvidia needs a depends=(linux-headers=version). All other modules work correctly with provides. Please submit a bug report to add provides to linux-lts. What really need is two provides, provides=4.14 and provides=4.14.x for kernel version particular modules. We could also make up fake package names so modules could depend on them or the original names as desired. Same as Java.

Scimmia commented on 2021-01-02 05:12 (UTC)

2 updates and the provides still isn't fixed

Scimmia commented on 2020-12-11 00:39 (UTC)

nvidia? broadcom-wl? Every single module in the repos?

severach commented on 2020-12-11 00:22 (UTC)

What package has such a module? Don't reference any DKMS packages because my settings are there to support those packages, not packages with kernel modules inexplicably compiled for the latest kernel but with no source available.

Scimmia commented on 2020-12-09 13:15 (UTC)

Really? So if you have a module built against the 'linux' package it will work with this kernel with no changes? Because that's what you're claiming.

severach commented on 2020-12-09 07:30 (UTC)

You're wrong because every kernel is a drop in replacement for every other kernel.

Scimmia commented on 2020-12-08 23:37 (UTC) (edited on 2020-12-09 05:32 (UTC) by Scimmia)

It doesn't work that way, that's not how provides works. Saying this provides linux means that it's a drop-in, binary replacement. It's not. If your modules require 'linux', that means that they're being built against the 'linux' kernel, or they're poorly packaged.

severach commented on 2020-12-08 18:30 (UTC)

No, in fact the opposite is true. The repo Linux LTS (currently 5.4) needs to PROVIDE linux. I build more than a dozen kernel modules. I add provides so they work properly. Try uninstalling the latest Linux and see how many things break.

Scimmia commented on 2020-12-08 15:01 (UTC)

You should really stop claiming that these packages provide 'linux'. They don't. If you have modules built for the 'linux' kernel, they won't work here. Same for 'linux-headers'

Rick commented on 2020-08-23 07:41 (UTC)

@severach, so I didn't wait long enough, will try again.

severach commented on 2020-08-23 01:36 (UTC)

The build is fine. It will take about 1.5 hours to build with -j2. It takes me 24 minutes with -j8.

Rick commented on 2020-08-22 08:30 (UTC)

It stops building after this line: + nice make -s -j 2 LOCALVERSION= bzImage modules CPU at 100%

ifreund commented on 2019-12-14 18:42 (UTC)

Hello, I'm getting the following error:

==> ERROR: A failure occurred in prepare().
/usr/share/makepkg/util/message.sh: line 47: QUIET: unbound variable
/usr/bin/makepkg: line 132: logpipe: unbound variable

Can't really figure out what's causing it. Anyone else getting this? Any advice?

rralf commented on 2019-11-11 19:35 (UTC)

My Synaptics Touchpad stopped working since ~two releases. On 4.19-lts it still works fine. But I can't see any obvious in the diff between the releases.

Does anyone experience similar issues?

python commented on 2019-04-14 18:29 (UTC)

@severach Please enable CONFIG_PINCTRL_AMD in config as without this option ELAN touchpad on AMD motherboards doesn't work at all

simona commented on 2019-01-13 11:06 (UTC)

exist a repository that give 4.19 4.14 4.9 4.4 already compiled?

severach commented on 2019-01-11 22:47 (UTC)

@simona, let it run. That means it's working.

hussam commented on 2019-01-11 19:28 (UTC)

Just switched from official linux-lts package to your 4.14.92 PKGBUILD. It's working very well. I hope they extend 4.14 support like they did with 4.9 and 4.4.

simona commented on 2019-01-11 18:33 (UTC)

it seem stop working (with all cpu core to 100%) on 'nice make -s -j 8 LOCALVERSION= bzImage modules'

severach commented on 2019-01-11 16:58 (UTC) (edited on 2019-01-11 16:58 (UTC) by severach)

I posted my issue. I also posted that it was gone but that's not correct. It isn't gone.

@simona that error is from makepkg not handling set -u. Your problem is before that.

simona commented on 2019-01-11 09:25 (UTC)

==> Avvio di build() in corso... + nice make -s -j 8 LOCALVERSION= bzImage modules

++ gettext 'Aborted by user! Exiting...' ++ trap_exit INT 'Aborted by user! Exiting...' ++ local signal=INT ++ shift ++ (( ! INFAKEROOT )) ++ echo ++ error 'Aborted by user! Exiting...' ++ local 'mesg=Aborted by user! Exiting...' ++ shift +++ gettext ERROR: ++ printf '==> ERRORE: Aborted by user! Exiting...\n' ==> ERRORE: Aborted by user! Exiting... /bin/makepkg: riga 120: srclinks: variabile non assegnata +++ clean_up +++ local EXIT_CODE=1 +++ (( INFAKEROOT )) +++ (( (EXIT_CODE == E_OK || EXIT_CODE == E_INSTALL_FAILED) && CLEANUP )) +++ remove_deps +++ (( ! RMDEPS )) +++ return 0

severach commented on 2019-01-10 03:31 (UTC)

4.19 is fine on my single drive systems. Many crashes on my mdadm systems, must run 4.14 or less.

camilojm commented on 2019-01-10 02:16 (UTC)

Thanks for this the new 4.19lts is too unstable

prasopita commented on 2019-01-02 17:10 (UTC)

Thanks a lot! I didn't know that.

severach commented on 2019-01-02 15:49 (UTC)

The key for kernel.org should be in your keyring. I took out the sign anyways.

prasopita commented on 2019-01-02 13:26 (UTC)

==> Verifying source file signatures with gpg... linux-4.14.tar ... FAILED (unknown public key 79BE3E4300411886) ==> ERROR: One or more PGP signatures could not be verified!

Am I doing something wrong?