[arch-dev-public] Virtualbox binary modules maintainer
Ehlo, Last maintainer of virtualbox binary modules has resigned. These packages[1] are generated from virtualbox-guest-dkms and virtualbox-host-dkms each time a new linux or linux-lts package are released. Is there a volunteer to take care of them and handle rebuilds ? Although, I would prefer remove them and let users build vbox modules with the dkms package. That handle perfectly multiple kernel installation and simplify our job. [1] virtualbox-guest-modules, virtualbox-guest-modules-lts, virtualbox-host-modules, virtualbox-host-modules-lts. -- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A
On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote:
Ehlo,
500-NOTAMAILSERVER
Last maintainer of virtualbox binary modules has resigned.
I guess this is/was you?
These packages[1] are generated from virtualbox-guest-dkms and virtualbox-host-dkms each time a new linux or linux-lts package are released.
Relevant pkgbases are 'virtualbox-modules' and 'virtualbox-modules-lts', since this isn't obvious from your package list.
Is there a volunteer to take care of them and handle rebuilds ?
I'm not interested, but this is pretty vague. How much time is involved? How often? Are there open bugs? Have you worked with upstream at all? Do they suck?
Although, I would prefer remove them and let users build vbox modules with the dkms package. That handle perfectly multiple kernel installation and simplify our job.
DKMS is pretty lousy without hook functionality in the package manager. The whole point is that you can trigger this seamlessly on install/upgrade. Dropping this means that you "simplify our job" by pushing off more responsibility on users. There *will* be bug reports if you just drop these packages.
[1] virtualbox-guest-modules, virtualbox-guest-modules-lts, virtualbox-host-modules, virtualbox-host-modules-lts.
-- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A
On 16/07/2014 19:39, Dave Reisner wrote:
On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote: I guess this is/was you? It was Bartłomiej.
I'm not interested, but this is pretty vague. How much time is involved? How often? Are there open bugs? Have you worked with upstream at all? Do they suck?
From upstream tarball, I create virtualbox-host-dkms and virtualbox-guest-dkms (split packages from virtualbox pkgbase). This is the "official" way of building vbox* kernel modules. All "real" modules bugs are handled in the virtualbox package. To provide pre-compiled version of these modules for our linux and linux-lts packages, we have virtualbox-modules and virtualbox-modules-lts. Each one generate 2 packages, one for modules required in the hypervisor and one for modules required in the vm. Note: We don't provides pre-compiled modules for linux-grsec. AFIR, rebuild of these packages occur when: - New release of virtualbox (I handle them) - New release of the attached kernel package - Someone open a BR because a rebuild was not done when the kernel was updated. There is currently one open bug report, which will be fixed when I will push the last release of vbox tonight. You can have an idea of the time needed looking at the package history[1].
DKMS is pretty lousy without hook functionality in the package manager. The whole point is that you can trigger this seamlessly on install/upgrade. I'm not sure the package manager is an issue here, what we want is build vbox modules for the running kernel.
If you enable dkms service, the modules you need for kernel you are running will be built and loaded during the boot. It's transparent. The problem is more around our way of dealing with kernel updates (removing running kernel headers) than pacman packages ordering. We already don't support the case when user upgrade the kernel and don't reboot (kernel vs modules mismatch) immediately.
There *will* be bug reports if you just drop these packages. Could you be more specific?
I have the feeling that using dkms packages will prevent bug reports coverings depmod or packages was not rebuilt for the current kernel. This also simplify management for non official kernels. Cheers, [1] https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/v... -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On Wed, Jul 16, 2014 at 09:05:50PM +0200, Sébastien Luttringer wrote:
On 16/07/2014 19:39, Dave Reisner wrote:
On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote: I guess this is/was you? It was Bartłomiej.
I'm not interested, but this is pretty vague. How much time is involved? How often? Are there open bugs? Have you worked with upstream at all? Do they suck?
From upstream tarball, I create virtualbox-host-dkms and virtualbox-guest-dkms (split packages from virtualbox pkgbase). This is the "official" way of building vbox* kernel modules. All "real" modules bugs are handled in the virtualbox package.
To provide pre-compiled version of these modules for our linux and linux-lts packages, we have virtualbox-modules and virtualbox-modules-lts. Each one generate 2 packages, one for modules required in the hypervisor and one for modules required in the vm.
Note: We don't provides pre-compiled modules for linux-grsec.
AFIR, rebuild of these packages occur when: - New release of virtualbox (I handle them) - New release of the attached kernel package - Someone open a BR because a rebuild was not done when the kernel was updated.
There is currently one open bug report, which will be fixed when I will push the last release of vbox tonight.
You can have an idea of the time needed looking at the package history[1].
DKMS is pretty lousy without hook functionality in the package manager. The whole point is that you can trigger this seamlessly on install/upgrade. I'm not sure the package manager is an issue here, what we want is build vbox modules for the running kernel.
...and you want to build modules for the kernel that was just installed, hence, you need package manager integration. See below for why you should care about this.
If you enable dkms service, the modules you need for kernel you are running will be built and loaded during the boot. It's transparent.
Building modules on boot is doing it too late. It's on the same plane as what our initscripts used to do -- call 'depmod -A' on bootup. It's too late, and you're asking for a race condition. What about dkms-based modules which you're trying to build into the initramfs? You now need to circumvent this whole process, build the modules manually, and then rebuild your initramfs. Calling this early enough that it tries to avoid some of the races will just mean that you're unnecessarily blocking boot for X minutes while you build modules. Unless I'm missing something, that's a lousy user experience. Please, if you really want this to be some defacto standard for how we handle third-party modules, we *really* need someone dedicated to adding hook support in pacman.
The problem is more around our way of dealing with kernel updates (removing running kernel headers) than pacman packages ordering. We already don't support the case when user upgrade the kernel and don't reboot (kernel vs modules mismatch) immediately.
There *will* be bug reports if you just drop these packages. Could you be more specific?
If you're touting DKMS as the new hotness, you will absolutely need to have replaces/conflicts on the DKMS package for the packages you want to obviate. Otherwise, these packages will remain installed and eventually conflict with a kernel update. Around that time, you'll see bug reports.
I have the feeling that using dkms packages will prevent bug reports coverings depmod or packages was not rebuilt for the current kernel.
This also simplify management for non official kernels.
This doesn't make sense. As I see it, nothing is simplified, because nothing changes for this use case. User-built kernels can use DKMS now, and they'll still be able to use after this change. The precompiled module packages never had any relevance.
Cheers,
[1] https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/v...
Looks like 6 people (including yourself) have handled about ~4 builds per month over the past year. Higher maintenance than most packages, but certainly no higher than the cost of maintaining a single kernel package (assuming you're Doing It Right™). Are you, as the virtualbox maintainer, not willing to accept this shared responsibility? d
On 16/07/2014 22:13, Dave Reisner wrote:
On Wed, Jul 16, 2014 at 09:05:50PM +0200, Sébastien Luttringer wrote:
On 16/07/2014 19:39, Dave Reisner wrote:
On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote: Building modules on boot is doing it too late. It's on the same plane as what our initscripts used to do -- call 'depmod -A' on bootup. It's too late, and you're asking for a race condition.
I am embarrassed I don't see why it's too late. I'm doing this for 3 years, maybe I'm a lucky idiot. We also have users who use vbox-dkms package doing this without any bug report about a race condition.
What about dkms-based modules which you're trying to build into the initramfs? There is few reason to embed vbox modules inside the initramfs, but anyway, I guess it's up to the initramfs software you use to trigger the build of dkms managed modules (for the requested kernel) it wants to ship.
Calling this early enough that it tries to avoid some of the races will just mean that you're unnecessarily blocking boot for X minutes while you build modules. Unless I'm missing something, that's a lousy user experience. The build can continue far after your KDE desktop environment has started. If you run virtualbox GUI before the build finish you will get
We can have an mkinitcpio hook which build all the dkms modules for the targeted kernel. However, the pacman ordering issue is back, until next release of pacman... which is, fortunately, expected in august. the message that modules are missing. I think our user are able to deal with that.
Please, if you really want this to be some defacto standard for how we handle third-party modules, we *really* need someone dedicated to adding hook support in pacman. I'm only suggesting this for virtualbox modules, but, you are right, we can simplify our way of managing all external modules by using dkms.
I know there are pros and cons to this solution, that's a team decision, not mine. I see this as a better simple stupid solution with our currrent tools.
There *will* be bug reports if you just drop these packages. Could you be more specific?
If you're touting DKMS as the new hotness, you will absolutely need to have replaces/conflicts on the DKMS package for the packages you want to obviate. Otherwise, these packages will remain installed and eventually conflict with a kernel update. Around that time, you'll see bug reports. ok, you are talking of bug reports during the transition phase.
So, if we do that, we should handle the transition smartly. I think to replaces/conflits and advertise in .install. We can even put a global announce if you think it's necessary. Don't believe that I'm in love with dkms. It's an helpful crap. I would prefer have a brand new Lennart systemd glue[1] or anything more elegant to manage out-of-tree modules. But it's currently the most spread solution.
Are you, as the virtualbox maintainer, not willing to accept this shared responsibility?
Remember the title of my mail. I didn't start by "Burn the vbox modules". I'm looking for someone who want to be maintainer of these packages to handle official kernels rebuild and deal with bug reports. Of course, I would prefer to drop them, because I feel them unnecessary. They slow down the release process (of the kernel and virtualbox) and cause issues. Cheers, [1] With depends (and wait) on modules instead of using systemd-modules-load. -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 16/07/2014 19:26, Sébastien Luttringer wrote:
Last maintainer of virtualbox binary modules has resigned. For the last releases of linux-lts[1], virtualbox-modules-lts[2] was not rebuilt, resulting in bug reports[3][4] with nobody interested to fix.
Is there a volunteer to take care of them and handle rebuilds ? Nobody raised his hand so far.
Until recently we share rebuild - I do a rebuild when I bump virtualbox (only major versions) - Kernel maintainers do a rebuild when they bump (all version) As confirmed in bug report[2], a simple fix is to use virtualbox dkms modules, but Dave asked to wait next pacman release to manage rebuild during pacman upgrade (with hooks) rather than dkms.service at boot. Now, I think it's better to drop them and have built at boot time instead of broken packages in the repo. [1] https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/li... [2] https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/v... [3] https://bugs.archlinux.org/task/41602 [4] https://bugs.archlinux.org/task/41375 -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
participants (2)
-
Dave Reisner
-
Sébastien Luttringer