On mer., 2016-03-09 at 12:10 +1000, Allan McRae wrote:
On 09/03/16 11:44, Sébastien Luttringer wrote:
On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
On 09/03/16 09:29, Sébastien Luttringer wrote:
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
1) pre pacman-5.0 updates unsupported without any prior notification
Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre- pacman 5 update to display a warning or handle it correctly?
There needs to be a public announcement made that we expected everyone to have updated to pacman-5.0 by <insert date here>. Then we start using hooks.
There is no way without breaking people updating their Arch from pacman 4.x after that random date?
That is the only way. Joys of rolling release.
If pacman was able to update itself first, as it does before, this would, rolling release or not, do the job?
As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed, Surely that is a five line script... Please provide it. We are building all our kernel modules manually for years.
How this will work? When I push a new version of virtualbox on svn a builder will pick the current kernel and build the modules from my dkms version and push them to the repo? Which key will sign these packages? How this will be synced with db-update? What has pushing a new version of virtualbox got to do with rebuilding modules when the kernel is updated? Rebuilding modules on kernel update is:
for pkg in <module package list>; do archco <pkg> // awk/sed line to bump pkgrel testing-x86_64-build && testing-i686-build testingpkg "module rebuild" done
OK - I was wrong. That is six lines (or seven if you count the line with && as two lines...).
We are definitely not talking of the same thing. I was talking of an automated way of building o-o-t modules when the dkms package is updated or the kernel is bumped. Was you are proposing, is what I referred as manually.
== Before going further, keep in mind that I'm open to bring back pre-built modules for virtualbox. But currently there is no rules and no coherence between our way of doing. Let me summarise the situation with the following table: | package name | linux | linux-lts | dkms | | acpi_call | yes | yes | no | | bbswitch | yes | yes | no | | nvidia | yes | yes | yes | | nvidia-340xx | yes | yes | yes | | nvidia-304xx | yes | yes | yes | | ndiswrapper-dkms | no | no | yes | | r8168 | yes | yes | no | | rt3562sta | yes | no | no | | sysdig | no | no | yes | | vhba-module | yes | no | no | | virtualbox-host-modules | no | no | yes | | virtualbox-guest-modules | no | no | yes | So, each maintainer do what he wants. 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. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A