Re: [arch-dev-public] Consensus: DKMS modules
On Tue, Mar 15, 2016 at 1:06 AM, Allan McRae wrote: > On 14/03/16 09:07, Allan McRae wrote: > > On 13/03/16 00:52, Sébastien Luttringer wrote: > >> Please note that as an ideal target, I would have all our kernel modules > >> available via dkms _and_ via prebuilt modules for each kernel flavor we > >> provide. I read on the dev IRC that few modules could only be shipped > from > >> sources. Not sure of that btw. > >> > >> For example, we could, for simplicity says that we provide pre-built > modules > >> only for the main kernel and dkms for all others kernels. > >> > >> What I would like is a team consensus/decision on how we handle kernel > oot > >> modules not complains directed on virtualbox only. > > > > > > I vote for binary modules for all kernels in [core] and dkms versions. > > Kernels outside of [core] can have binary modules provided at the > > maintainer's choice. > > > > We are going to need more opinions here to build a consensus... > > A > Having used the ck kernel for years, and now zen, I am somehow biased and in favor of DKMS everywhere, that and it really puts a burden on our kernel maintainers having to build all our OOT modules with every upgrade. It really doesn't take that much time to build them, even on modest machines (got nvidia, bbswitch, vboxhost and cdemu on my laptop). Also I know some people disagree, but kernel headers don't take that much space, bandwidth may be another story though. That being said, I feel that what Sebastien proposed, ie having built modules only for linux and linux-lts, and DKMS everywhere else would be a good compromise IMHO. Cheers, -- Maxime
Re: [arch-dev-public] Consensus: DKMS modules
On 15.03.2016 08:26, Maxime Gauduin wrote: > It really doesn't take that much time to build them, even on modest > machines (got nvidia, bbswitch, vboxhost and cdemu on my laptop). I really feel like vbox takes way too long to build. It's probably not longer than 15 seconds, but it produces so much output that it feels slow (well and because it is when compared to how fast the archive would be extracted). > That being said, I feel that what Sebastien proposed, ie having built > modules only for linux and linux-lts, and DKMS everywhere else would be a > good compromise IMHO. Please go that route. We are a binary distro and I'd prefer to have as many packages prebuilt as possible. I'm always reminded of that when I build perl modules from cpan. Installing 20 modules from the repos is done in like 10 seconds while building them takes something like 1 to 10 minutes (yay tests). Florian signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Consensus: DKMS modules
On 15 March 2016 at 01:06, Allan McRae wrote: > On 14/03/16 09:07, Allan McRae wrote: >> >> >> I vote for binary modules for all kernels in [core] and dkms versions. >> Kernels outside of [core] can have binary modules provided at the >> maintainer's choice. >> > > We are going to need more opinions here to build a consensus... > > A While I like the idea of having DKMS in the repo, I'm strongly in favor of having binary modules for kernels from [core] Lukas
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 16 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 2 fully signed off packages * 48 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (16 total) == * iproute2-4.4.0-1 (i686) * iw-4.3-1 (i686) * krb5-1.13.4-1 (i686) * libnl-3.2.27-1 (i686) * mkinitcpio-busybox-1.24.1-1 (i686) * openvpn-2.3.10-1 (i686) * iproute2-4.4.0-1 (x86_64) * iw-4.3-1 (x86_64) * krb5-1.13.4-1 (x86_64) * libnl-3.2.27-1 (x86_64) * mkinitcpio-busybox-1.24.1-1 (x86_64) * openvpn-2.3.10-1 (x86_64) * telepathy-gabble-0.18.3-3 (i686) * valgrind-3.11.0-3 (i686) * telepathy-gabble-0.18.3-3 (x86_64) * valgrind-3.11.0-3 (x86_64) == Incomplete signoffs for [core] (28 total) == * cracklib-2.9.6-1 (i686) 0/1 signoffs * dbus-1.10.8-1 (i686) 0/1 signoffs * expat-2.1.1-1 (i686) 0/1 signoffs * grep-2.24-1 (i686) 0/1 signoffs * iproute2-4.4.0-1 (i686) 0/1 signoffs * iputils-20160308.0db72a4-1 (i686) 0/1 signoffs * iw-4.3-1 (i686) 0/1 signoffs * krb5-1.13.4-1 (i686) 0/1 signoffs * libnl-3.2.27-1 (i686) 0/1 signoffs * lvm2-2.02.146-1 (i686) 0/1 signoffs * mkinitcpio-busybox-1.24.1-1 (i686) 0/1 signoffs * mpfr-3.1.4-1 (i686) 0/1 signoffs * nss-3.23-1 (i686) 0/1 signoffs * openvpn-2.3.10-1 (i686) 0/1 signoffs * pkg-config-0.29.1-1 (i686) 0/1 signoffs * cracklib-2.9.6-1 (x86_64) 0/2 signoffs * expat-2.1.1-1 (x86_64) 0/2 signoffs * grep-2.24-1 (x86_64) 0/2 signoffs * iproute2-4.4.0-1 (x86_64) 1/2 signoffs * iputils-20160308.0db72a4-1 (x86_64) 0/2 signoffs * iw-4.3-1 (x86_64) 0/2 signoffs * krb5-1.13.4-1 (x86_64) 0/2 signoffs * libnl-3.2.27-1 (x86_64) 0/2 signoffs * lvm2-2.02.146-1 (x86_64) 0/2 signoffs * mkinitcpio-busybox-1.24.1-1 (x86_64) 0/2 signoffs * mpfr-3.1.4-1 (x86_64) 1/2 signoffs * nss-3.23-1 (x86_64) 1/2 signoffs * openvpn-2.3.10-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (20 total) == * digikam-4.14.0-6 (i686) 0/1 signoffs * fontconfig-2.11.94-1 (i686) 0/1 signoffs * glib-networking-2.47.90-1 (i686) 0/1 signoffs * gst-plugins-bad-1.6.3-7 (i686) 0/1 signoffs * libkface-15.12.2-2 (i686) 0/1 signoffs * libkface4-15.08.3-3 (i686) 0/1 signoffs * opencv-3.1.0-3 (i686) 0/1 signoffs * telepathy-gabble-0.18.3-3 (i686) 0/1 signoffs * valgrind-3.11.0-3 (i686) 0/1 signoffs * xorg-server-1.18.2-1 (i686) 0/1 signoffs * digikam-4.14.0-6 (x86_64) 0/2 signoffs * fontconfig-2.11.94-1 (x86_64) 0/2 signoffs * glib-networking-2.47.90-1 (x86_64) 0/2 signoffs * gst-plugins-bad-1.6.3-7 (x86_64) 0/2 signoffs * libkface-15.12.2-2 (x86_64) 0/2 signoffs * libkface4-15.08.3-3 (x86_64) 0/2 signoffs * opencv-3.1.0-3 (x86_64) 0/2 signoffs * telepathy-gabble-0.18.3-3 (x86_64) 0/2 signoffs * valgrind-3.11.0-3 (x86_64) 0/2 signoffs * xorg-server-1.18.2-1 (x86_64) 0/2 signoffs == Completed signoffs (2 total) == * dbus-1.10.8-1 (x86_64) * pkg-config-0.29.1-1 (x86_64) == Top five in signoffs in last 24 hours == 1. eworm - 2 signoffs
Re: [arch-dev-public] Consensus: DKMS modules
On 15.03.2016 01:06, Allan McRae wrote: On 14/03/16 09:07, Allan McRae wrote: On 13/03/16 00:52, Sébastien Luttringer wrote: Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw. For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels. What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only. I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice. We are going to need more opinions here to build a consensus... A I agree. There is no point in having every user building the exact same module on every update. That's why we package precompiled packages. This looks more like a workaround of how kernel and module updates are handled atm. E.g. the kernel stays in testing for a long time and is not put into staging first so packagers can rebuild their modules. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Consensus: DKMS modules
[2016-03-15 10:06:22 +1000] Allan McRae: > On 14/03/16 09:07, Allan McRae wrote: > > On 13/03/16 00:52, Sébastien Luttringer wrote: > >> Please note that as an ideal target, I would have all our kernel modules > >> available via dkms _and_ via prebuilt modules for each kernel flavor we > >> provide. I read on the dev IRC that few modules could only be shipped from > >> sources. Not sure of that btw. > >> > >> For example, we could, for simplicity says that we provide pre-built > >> modules > >> only for the main kernel and dkms for all others kernels. > >> > >> What I would like is a team consensus/decision on how we handle kernel oot > >> modules not complains directed on virtualbox only. > > > > > > I vote for binary modules for all kernels in [core] and dkms versions. > > Kernels outside of [core] can have binary modules provided at the > > maintainer's choice. > > > > We are going to need more opinions here to build a consensus... To me the issue is people pushing new kernels to the repos but not being able to provide the same level of support that we have for mainline. Offloading out-of-tree module rebuilds to end users instead of doing it ourselves is clearly not the right solution. So I say: remove each non-mainline kernel of which the maintainer is unwilling to support the corresponding out-of-tree modules. After all, as Allan points out, rebuilding them is a simple script job... Cheers. -- Gaetan
Re: [arch-dev-public] Consensus: DKMS modules
> To me the issue is people pushing new kernels to the repos but not > being > able to provide the same level of support that we have for mainline. > Offloading out-of-tree module rebuilds to end users instead of doing > it > ourselves is clearly not the right solution. > > So I say: remove each non-mainline kernel of which the maintainer is > unwilling to support the corresponding out-of-tree modules. After > all, > as Allan points out, rebuilding them is a simple script job... > > Cheers. In general, out-of-tree modules aren't compatible with linux-grsec. It is not enough to simply rebuild them. It would require actively keeping them compatible by maintaining patches for them and possibly working with the upstreams for the out-of-tree modules for cases where bugs are being uncovered rather than false positives / tweaks for compatibility. Some out-of-tree modules aren't going to be compatible with the chosen configuration at all, similar to how Xen support is disabled in favour of having the hardening features marked as incompatible with it. The NVIDIA driver and broadcom-wl need to be patched and and VirtualBox is semi-incompatible with the chosen configuration. AFAIK, users would need to rebuild the kernel with a couple options disabled for all the VirtualBox features to work. signature.asc Description: This is a digitally signed message part
