Re: [arch-dev-public] Conclusion: DKMS modules

[Gaetan Bisson]

Sébastien,

[2016-03-23 22:28:36 +0100] Sébastien Luttringer:
> Unexpectedly we got the most feedback from persons who are not dealing
> currently with the burden of managing kernels and their modules.

It's been more than two weeks since Allan's original message; everybody
who wanted to contribute to this discussion has contributed. There's
really no need to try and discredit the whole thread with a classical
"the silent majority sides with me" fallacy.

> 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.

Seriously, man, how do you go from "no one objects to having dkms" to
"we must provide dkms"?

I mean, we're all trying to have a reasonable discussion here. On this
mailing list more than anywhere else. Please refrain from jumping to
your own conclusions all the time, it's really annoying, in particular
when you have to twist the logic of other people's arguments for that.

Allan already pointed this out, but I feel like I must insist:

> 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).

Absolutely no. We are a binary distribution. Binary should be the
default. Nobody but you argued otherwise.

> 6) Binary modules should be built from the dkms package.

Wow! Where on earth do you get crazy stuff like that from? It's never
been part of this discussion. And what purpose would his additional
requirement serve exactly?

I really wish you'd argue in good faith instead of simply trying to
steer things your way.

Cheers.

-- 
Gaetan


signature.asc
Description: PGP signature

Re: [arch-dev-public] Conclusion: DKMS modules

[Allan McRae]

On 24/03/16 07:28, Sébastien Luttringer wrote:
> On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
>> Having given everyone time to reply (not that many did...), the
>> consensus of those that replied is:
>>
>> - Binary modules are to be provided at minimum of all kernels in [core],
>> with preference to providing them for all supported kernels (noting that
>> out-of-tree modules may not work with some patched kernels).
>>
>> - There is no objection to providing DKMS modules in the repos, but this
>> is secondary to binary modules.  No opinions were stated on whether we
>> ensure all modules have DKMS variants in the repos.
>>
>> I decree by the power invested in me through talking the loudest, that
>> this is now our policy.
>>
> 
> Unexpectedly we got the most feedback from persons who are not dealing
> currently with the burden of managing kernels and their modules. Like you I 
> was
> expecting more opinions.
> 
> Even I support your will of moving forward regarding all this discussion, I
> don't share your conclusions nor the fact that one of us could speak lourder 
> to
> impose his will to others.

It was a joke.   Although those of us that have been around here 10
years have loud voices...

> I have few more subjects to discuss altogether where
> I hope we could take team directions by constructive discussions and not
> decree.
> 
> ==
> 
> I give a second read to all emails exchanged since my original one about 
> o-o-t-
> m at 19th February and I come to this:
> 
> 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. The Florian said "please go that route". Lukas was
strongly in favour "of have binary modules for kernels from [core]".

Gatean was in favour of having all kernels support binary modules.

Hence my conclusion:

"Binary modules are to be provided at minimum of all kernels in [core],
 with preference to providing them for all supported kernels (noting
that out-of-tree modules may not work with some patched kernels)."


> 2) No one object to a module exclusion from a specific kernel when it make no
> sense Examples was provided with GRSEC.
> ==> We could exclude modules support for a kernel for technical reasons.

Hence the "noting that out-of-tree modules may not work with some
patched kernels" in my conclusion.

> 3) There is a consensus on having binary modules in our repositories.
> ==> We must provides binary modules for all kernels. Except those covered by 
> 2.

See 1).

> 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.

> 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.

> 6) Binary modules should be built from the dkms package. This was not 
> discussed
> earlier, but I see a benefits to have a common way of building modules and
> testing the dkms package in one row. 

Not part of the discussion.  The maintainers of the packages can have a
separate discussion about this.

> 7) https://bugs.archlinux.org/task/48498
> ==> kernels packages should provides kernel=$version and kernel-
> headers=$version in order to let dkms modules maintainers require at least a
> kernel and its header to be installed.

Off-topic for this discussion.

> This is the policy I propose we adopt.
> 
> Note that this policy is not defining who is responsible of what. We could 
> keep
> our current way of doing. I mean:
> - When a kernel is upgraded, it's kernel maintainer responsibility to upgrade
> all binary modules

It already is, unless they put the package in [staging] and create a
rebuild list.  Same as every other package.

> - When a module is upgraded, it's the modules maintainer responsibility to
> build the module for all kernels in stable and in testing (This is boring).

It already is.  If you don't like doing it, don't maintain the package.

A

Re: [arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
> Having given everyone time to reply (not that many did...), the
> consensus of those that replied is:
> 
> - Binary modules are to be provided at minimum of all kernels in [core],
> with preference to providing them for all supported kernels (noting that
> out-of-tree modules may not work with some patched kernels).
> 
> - There is no objection to providing DKMS modules in the repos, but this
> is secondary to binary modules.  No opinions were stated on whether we
> ensure all modules have DKMS variants in the repos.
> 
> I decree by the power invested in me through talking the loudest, that
> this is now our policy.
> 

Unexpectedly we got the most feedback from persons who are not dealing
currently with the burden of managing kernels and their modules. Like you I was
expecting more opinions.

Even I support your will of moving forward regarding all this discussion, I
don't share your conclusions nor the fact that one of us could speak lourder to
impose his will to others.
I have few more subjects to discuss altogether where
I hope we could take team directions by constructive discussions and not
decree.

==

I give a second read to all emails exchanged since my original one about o-o-t-
m at 19th February and I come to this:

1) No one support that we should manage kernels differently because they are
under different repository.
==> We must manage them all the same way.

2) No one object to a module exclusion from a specific kernel when it make no
sense Examples was provided with GRSEC.
==> We could exclude modules support for a kernel for technical reasons.

3) There is a consensus on having binary modules in our repositories.
==> We must provides binary modules for all kernels. Except those covered by 2.

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.

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).

6) Binary modules should be built from the dkms package. This was not discussed
earlier, but I see a benefits to have a common way of building modules and
testing the dkms package in one row. 

7) https://bugs.archlinux.org/task/48498
==> kernels packages should provides kernel=$version and kernel-
headers=$version in order to let dkms modules maintainers require at least a
kernel and its header to be installed.

This is the policy I propose we adopt.

Note that this policy is not defining who is responsible of what. We could keep
our current way of doing. I mean:
- When a kernel is upgraded, it's kernel maintainer responsibility to upgrade
all binary modules
- When a module is upgraded, it's the modules maintainer responsibility to
build the module for all kernels in stable and in testing (This is boring).

Cheers,

-- 
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] ANNOUNCEMENT: pacman hooks

[Thorsten Töpper]

On Wed, 23 Mar 2016 13:30:45 +1000
Allan McRae  wrote:

> Hi all,
> 
- snip -
> 
> --DRAFT--
> Required update to pacman-5.0.1 before 2016-04-17
> 
> The release of pacman-5.0 bought support for transactional hooks.
> These will allow us to (e.g.) run font cache updates a single time
> during an update rather than after each font package.  This will both
> speed up the update process, but also reduce packaging burden for the
> Developers and Trusted Users.
> 
> In order for the use of hooks to be started, we require all users to
> have updated to at least pacman-5.0.1 before 2016-04-23. Pacman-5.0.1
> was released on 2016-02-23, so this will have given everyone two
> months to update their system.
> --END DRAFT--
> 
> Comments?
> 
> Allan

Hi Allan,

looks good except for the date. April 17 or 23? Probably the latter.

Cheers,
Thorsten


pgpckBXWXPHQP.pgp
Description: OpenPGP digital signature

[arch-dev-public] Signoff report for [testing]

[Arch Website Notification]

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 219 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 5 fully signed off packages
* 316 packages missing signoffs
* 2 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 (219 total) ==

* breeze-icons-5.20.0-1 (any)
* extra-cmake-modules-5.20.0-1 (any)
* kapidox-5.20.0-1 (any)
* oxygen-icons-1:5.20.0-1 (any)
* plasma-meta-5.6-1 (any)
* plasma-workspace-wallpapers-5.6.0-1 (any)
* attica-qt5-5.20.0-1 (i686)
* baloo-5.20.0-1 (i686)
* bluedevil-1:5.6.0-1 (i686)
* bluez-qt-5.20.0-1 (i686)
* breeze-5.6.0-1 (i686)
* breeze-gtk-5.6.0-1 (i686)
* frameworkintegration-5.20.0-1 (i686)
* jsoncpp-1.7.1-1 (i686)
* kactivities-5.20.0-2 (i686)
* karchive-5.20.0-1 (i686)
* kauth-5.20.0-1 (i686)
* kbookmarks-5.20.0-1 (i686)
* kcmutils-5.20.0-1 (i686)
* kcodecs-5.20.0-1 (i686)
* kcompletion-5.20.0-1 (i686)
* kconfig-5.20.0-1 (i686)
* kconfigwidgets-5.20.0-1 (i686)
* kcoreaddons-5.20.0-1 (i686)
* kcrash-5.20.0-1 (i686)
* kdbusaddons-5.20.0-1 (i686)
* kde-cli-tools-5.6.0-1 (i686)
* kde-gtk-config-5.6.0-1 (i686)
* kdeclarative-5.20.0-1 (i686)
* kdecoration-5.6.0-1 (i686)
* kded-5.20.0-1 (i686)
* kdelibs4support-5.20.0-1 (i686)
* kdeplasma-addons-5.6.0-1 (i686)
* kdesignerplugin-5.20.0-1 (i686)
* kdesu-5.20.0-1 (i686)
* kdewebkit-5.20.0-1 (i686)
* kdnssd-5.20.0-1 (i686)
* kdoctools-5.20.0-1 (i686)
* kemoticons-5.20.0-1 (i686)
* kfilemetadata-5.20.0-1 (i686)
* kgamma5-5.6.0-1 (i686)
* kglobalaccel-5.20.0-1 (i686)
* kguiaddons-5.20.0-1 (i686)
* khelpcenter-5.5.95-1 (i686)
* khotkeys-5.6.0-1 (i686)
* khtml-5.20.0-1 (i686)
* ki18n-5.20.0-1 (i686)
* kiconthemes-5.20.0-1 (i686)
* kidletime-5.20.0-1 (i686)
* kimageformats-5.20.0-1 (i686)
* kinfocenter-5.6.0-1 (i686)
* kinit-5.20.0-1 (i686)
* kio-5.20.0-2 (i686)
* kitemmodels-5.20.0-1 (i686)
* kitemviews-5.20.0-1 (i686)
* kjobwidgets-5.20.0-1 (i686)
* kjs-5.20.0-1 (i686)
* kjsembed-5.20.0-1 (i686)
* kmediaplayer-5.20.0-1 (i686)
* kmenuedit-5.6.0-1 (i686)
* knewstuff-5.20.0-1 (i686)
* knotifications-5.20.0-1 (i686)
* knotifyconfig-5.20.0-1 (i686)
* kpackage-5.20.0-1 (i686)
* kparts-5.20.0-1 (i686)
* kpeople-5.20.0-1 (i686)
* kplotting-5.20.0-1 (i686)
* kpty-5.20.0-1 (i686)
* kross-5.20.0-1 (i686)
* krunner-5.20.0-1 (i686)
* kscreen-5.6.0-1 (i686)
* kscreenlocker-5.6.0-1 (i686)
* kservice-5.20.0-1 (i686)
* ksshaskpass-5.6.0-1 (i686)
* ksysguard-5.6.0-1 (i686)
* ktexteditor-5.20.0-1 (i686)
* ktextwidgets-5.20.0-1 (i686)
* kunitconversion-5.20.0-1 (i686)
* kwallet-5.20.0-1 (i686)
* kwallet-pam-5.6.0-1 (i686)
* kwayland-5.6.0-1 (i686)
* kwayland-integration-5.6.0-1 (i686)
* kwidgetsaddons-5.20.0-1 (i686)
* kwin-5.6.0-1 (i686)
* kwindowsystem-5.20.0-1 (i686)
* kwrited-5.6.0-1 (i686)
* kxmlgui-5.20.0-1 (i686)
* kxmlrpcclient-5.20.0-1 (i686)
* libkscreen-5.6.0-1 (i686)
* libksysguard-5.6.0-1 (i686)
* milou-5.6.0-1 (i686)
* modemmanager-qt-5.20.0-1 (i686)
* networkmanager-qt-5.20.0-1 (i686)
* oxygen-5.6.0-1 (i686)
* plasma-desktop-5.6.0-1 (i686)
* plasma-framework-5.20.0-2 (i686)
* plasma-mediacenter-5.6.0-1 (i686)
* plasma-nm-5.5.95-1 (i686)
* plasma-pa-5.5.95-1 (i686)
* plasma-sdk-5.6.0-1 (i686)
* plasma-workspace-5.6.0-1 (i686)
* polkit-kde-agent-5.6.0-1 (i686)
* powerdevil-5.6.0-1 (i686)
* sddm-kcm-5.6.0-1 (i686)
* solid-5.20.0-1 (i686)
* sonnet-5.20.0-1 (i686)
* spectacle-15.12.3-2 (i686)
* systemsettings-5.6.0-1 (i686)
* threadweaver-5.20.0-1 (i686)
* user-manager-5.6.0-1 (i686)
* attica-qt5-5.20.0-1 (x86_64)
* baloo-5.20.0-1 (x86_64)
* bluedevil-1:5.6.0-1 (x86_64)
* bluez-qt-5.20.0-1 (x86_64)
* breeze-5.6.0-1 (x86_64)
* breeze-gtk-5.6.0-1 (x86_64)
* frameworkintegration-5.20.0-1 (x86_64)
* jsoncpp-1.7.1-1 (x86_64)
* kactivities-5.20.0-2 (x86_64)
* karchive-5.20.0-1 (x86_64)
* kauth-5.20.0-1 (x86_64)
* kbookmarks-5.20.0-1 (x86_64)
* kcmutils-5.20.0-1 (x86_64)
* kcodecs-5.20.0-1 (x86_64)
* kcompletion-5.20.0-1 (x86_64)
* kconfig-5.20.0-1 (x86_64)
* kconfigwidgets-5.20.0-1 (x86_64)
* kcoreaddons-5.20.0-1 (x86_64)
* kcrash-5.20.0-1 (x86_64)
* kdbusaddons-5.20.0-1 (x86_64)
* kde-cli-tools-5.6.0-1 (x86_64)
* kde-gtk-config-5.6.0-1 (x86_64)
* kdeclarative-5.20.0-1 (x86_64)
* kdecoration-5.6.0-1 (x86_64)
* kded-5.20.0-1 (x86_64)
* kdelibs4support-5.20.0-1 (x86_64)
* kdeplasma-addons-5.6.0-1 (x86_64)
* kdesignerplugin-5.20.0-1 (x86_64)
* kdesu-5.20.0-1 (x86_64)
* kdewebkit-5.20.0-1 (x86_64)
* kdnssd-5.20.0-1 (x86_64)
* kdoctools-5.20.0-1 (x86_64)
* kemoticons-5.20.0-1 (x86_64)
* kfilemetadata-5.20.0-1 (x86_64)
* kgamma5-5.6.0-1 (x86_64)
* kglobalaccel-5.20.0-1 (x86_64)
* kguiaddons-5.20.0-1 (x86_64)
* khelpcenter-5.6.0-1 (x86_64)
* khotkeys-5.6.0-1 (x86_64)
* khtml-5.20.0-1 (x86_64)
* ki18n-5.20.0-1 (x86_64)
* kiconthemes-5.20.0-1