Re: [arch-dev-public] Conclusion: DKMS modules
[2016-04-13 02:05:13 +0200] Sébastien Luttringer: > I started promoting a way to manage o-o-t modules with only dkms. > During the discussion, providing binary modules make consensus. So, I made a > concession and moved to a position close to yours, which can be sum as, if we > provide binary modules, we should provides them for all kernels. That's not at all how I understood your last message. I'm sorry you had to take a break from Arch and I apologize if my reply was part of the problem in any way, but I still think what you said goes against most of the views other developers have expressed in this thread. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Conclusion: DKMS modules
On mer., 2016-03-23 at 18:51 -1000, Gaetan Bisson wrote: > bla bla > > I really wish you'd argue in good faith instead of simply trying to > steer things your way. I started promoting a way to manage o-o-t modules with only dkms. During the discussion, providing binary modules make consensus. So, I made a concession and moved to a position close to yours, which can be sum as, if we provide binary modules, we should provides them for all kernels. Despite this 180° move, you ask me to not steer things my way. On the other things you wrote, even after a 2 weeks break from Arch, the only discredit I see from the whole discussion is from you and directed to me. -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Conclusion: DKMS modules
On jeu., 2016-03-24 at 08:29 +1000, Allan McRae wrote: > On 24/03/16 07:28, Sébastien Luttringer wrote: > > > > On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote: > > 1) No one support that we should manage kernels differently because they > > are under different repository. > > ==> We must manage them all the same way. > I did. > > Maxime said building modules for only linux and linux-lts is a > good compromise. Maxime says exactly: "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." Unfortunately, I never proposed linux-lts, it was you. So, I asked you the reason on IRC: [2016-03-21 20:32:47] amcrae: why do you want to manage core kernels differently than others? And moreover, who cares of -lts nowdays? [2016-03-21 23:50:44] seblu: I don't want to manage core kernels different - preferably all kernels are provided with binary modules Reading this, and as you were behind the "core kernels" group, I was expecting you conclude to binary module for the arch kernel, dkms for the rest. Which is not coherent with the "we are a binary distro", but a common ground. > > 4) No one object to having dkms available for all modules; It's even > > supported > > by several fellows and this is offering support for AUR and custom kernels > > at > > almost no maintenance cost. > > ==> We must provides dkms build for all modules. Except those covered by 2. > As I said, no-one objected to DKMS modules. But no opinions were stated > whether they must be provided. I did, and Maxime: "I am somehow biased and in favor of DKMS everywhere" Florian: "Please go that route" (the route also refer to DKMS everywhere). Bartłomiej: "IMHO we should have DKMS for all external modules" Lukas: "I like the idea of having DKMS in the repo" > > 5) There is no much discussion about which should be the default (a binary > > flavor or dkms). I would propose a solution which let the user choose which > > module he want needs by pulling a defined dep like module-$modulename. > > ==> Applications should pull a generic deps to let users decide which > > module he > > wants (flavored or dkms). > REALLY? You need to read that thread again. Default binary was > strongly supported. Yes, binaries are preferred, that was not my point. The keyword was flavor. For example, vbox was pulling the binary modules for the -arch kernel by default, not the -lts one or others. As we don't have a way to select the correct kernel version I find more elegant to pull a virtual name which is provided. But like point 6 and 7, I feel you'll claim that is not part of the discussion. So, let's see that later. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A signature.asc Description: This is a digitally signed message part
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 28 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 6 fully signed off packages * 200 packages missing signoffs * 33 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 (28 total) == * dhcpcd-6.10.2-1 (i686) * gnutls-3.4.11-1 (i686) * libtasn1-4.8-1 (i686) * dhcpcd-6.10.2-1 (x86_64) * gnutls-3.4.11-1 (x86_64) * libtasn1-4.8-1 (x86_64) * apache-2.4.20-1 (i686) * gnome-shell-3.20.0-3 (i686) * gtk3-3.20.3-1 (i686) * kapptemplate-15.12.3-2 (i686) * libglvnd-0.1.0.20160411-1 (i686) * nvidia-364.16-2 (i686) * nvidia-lts-364.16-2 (i686) * nvidia-settings-364.12-1 (i686) * nvidia-utils-364.16-1 (i686) * rhythmbox-3.3.1-1 (i686) * shared-mime-info-1.6-1 (i686) * apache-2.4.20-1 (x86_64) * gnome-shell-3.20.0-3 (x86_64) * gtk3-3.20.3-1 (x86_64) * kapptemplate-15.12.3-2 (x86_64) * libglvnd-0.1.0.20160411-1 (x86_64) * nvidia-364.16-2 (x86_64) * nvidia-lts-364.16-2 (x86_64) * nvidia-settings-364.12-1 (x86_64) * nvidia-utils-364.16-1 (x86_64) * rhythmbox-3.3.1-1 (x86_64) * shared-mime-info-1.6-1 (x86_64) == Incomplete signoffs for [core] (22 total) == * archlinux-keyring-20160402-1 (any) 0/2 signoffs * btrfs-progs-4.5-1 (i686) 0/1 signoffs * cracklib-2.9.6-1 (i686) 0/1 signoffs * dhcpcd-6.10.2-1 (i686) 0/1 signoffs * elfutils-0.166-1 (i686) 0/1 signoffs * gnutls-3.4.11-1 (i686) 0/1 signoffs * iproute2-4.4.0-2 (i686) 0/1 signoffs * iptables-1.6.0-1 (i686) 0/1 signoffs * iputils-20160308.0db72a4-1 (i686) 0/1 signoffs * krb5-1.13.4-1 (i686) 0/1 signoffs * libtasn1-4.8-1 (i686) 0/1 signoffs * linux-4.5-1 (i686) 0/1 signoffs * logrotate-3.9.2-1 (i686) 0/1 signoffs * lvm2-2.02.149-1 (i686) 0/1 signoffs * btrfs-progs-4.5-1 (x86_64) 1/2 signoffs * dhcpcd-6.10.2-1 (x86_64) 0/2 signoffs * elfutils-0.166-1 (x86_64) 0/2 signoffs * gnutls-3.4.11-1 (x86_64) 0/2 signoffs * iproute2-4.4.0-2 (x86_64) 1/2 signoffs * libtasn1-4.8-1 (x86_64) 0/2 signoffs * logrotate-3.9.2-1 (x86_64) 1/2 signoffs * lvm2-2.02.149-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (176 total) == * breeze-icons-5.21.0-1 (any) 0/2 signoffs * extra-cmake-modules-5.21.0-1 (any) 0/2 signoffs * kapidox-5.21.0-1 (any) 0/2 signoffs * oxygen-icons-1:5.21.0-1 (any) 0/2 signoffs * apache-2.4.20-1 (i686) 0/1 signoffs * attica-qt5-5.21.0-1 (i686) 0/1 signoffs * baloo-5.21.0-1 (i686) 0/1 signoffs * bluez-qt-5.21.0-1 (i686) 0/1 signoffs * digikam-4.14.0-6 (i686) 0/1 signoffs * ebtables-2.0.10_4-6 (i686) 0/1 signoffs * frameworkintegration-5.21.0-1 (i686) 0/1 signoffs * gnome-shell-3.20.0-3 (i686) 0/1 signoffs * gtk3-3.20.3-1 (i686) 0/1 signoffs * kactivities-5.21.0-1 (i686) 0/1 signoffs * kapptemplate-15.12.3-2 (i686) 0/1 signoffs * karchive-5.21.0-1 (i686) 0/1 signoffs * kauth-5.21.0-1 (i686) 0/1 signoffs * kbookmarks-5.21.0-1 (i686) 0/1 signoffs * kcmutils-5.21.0-1 (i686) 0/1 signoffs * kcodecs-5.21.0-1 (i686) 0/1 signoffs * kcompletion-5.21.0-1 (i686) 0/1 signoffs * kconfig-5.21.0-1 (i686) 0/1 signoffs * kconfigwidgets-5.21.0-1 (i686) 0/1 signoffs * kcoreaddons-5.21.0-1 (i686) 0/1 signoffs * kcrash-5.21.0-1 (i686) 0/1 signoffs * kdbusaddons-5.21.0-1 (i686) 0/1 signoffs * kdeclarative-5.21.0-1 (i686) 0/1 signoffs * kded-5.21.0-1 (i686) 0/1 signoffs * kdelibs4support-5.21.0-1 (i686) 0/1 signoffs * kdesignerplugin-5.21.0-1 (i686) 0/1 signoffs * kdesu-5.21.0-1 (i686) 0/1 signoffs * kdewebkit-5.21.0-1 (i686) 0/1 signoffs * kdnssd-5.21.0-1 (i686) 0/1 signoffs * kdoctools-5.21.0-1 (i686) 0/1 signoffs * kemoticons-5.21.0-1 (i686) 0/1 signoffs * kfilemetadata-5.21.0-1 (i686) 0/1 signoffs * kglobalaccel-5.21.0-1 (i686) 0/1 signoffs * kguiaddons-5.21.0-1 (i686) 0/1 signoffs * khtml-5.21.0-1 (i686) 0/1 signoffs * ki18n-5.21.0-1 (i686) 0/1 signoffs * kiconthemes-5.21.0-1 (i686) 0/1 signoffs * kidletime-5.21.0-1 (i686) 0/1 signoffs * kimageformats-5.21.0-1 (i686) 0/1 signoffs * kinit-5.21.0-1 (i686) 0/1 signoffs * kio-5.21.0-1 (i686) 0/1 signoffs * kitemmodels-5.21.0-1 (i686) 0/1 signoffs * kitemviews-5.21.0-1 (i686) 0/1 signoffs * kjobwidgets-5.21.0-1 (i686) 0/1 signoffs * kjs-5.21.0-1 (i686) 0/1 signoffs * kjsembed-5.21.0-1 (i686) 0/1 signoffs * kmediaplayer-5.21.0-1 (i686) 0/1 signoffs * knewstuff-5.21.0-1 (i686) 0/1 signoffs * knotifications-5.21.0-1 (i686) 0/1 signoffs * knotifyconfig-5.21.0-1 (i686) 0/1 signoffs * kpackage-5.21.0-1 (i686) 0/1 signoffs * kparts-5.21.0-1 (i686) 0/1 signoffs *
