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
signature.asc
Description: This is a digitally signed message part
