On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch <karol@babioch.de> wrote:
> Hi,
>
> Am 23.07.2012 02:01, schrieb Sébastien Luttringer:
>> You will be able to build your virtualbox modules by running
>> $ dkms install vboxhost/4.1.18
>> or you can let dkms rc script compile/install/load your modules with
>> $ rc.d start dkms

To be clear

You can still use virtualbox-modules to have your module pre-compiled
for the arch kernel.
If you have a custom kernel or want compile yourself your modules your
can use virtualbox-sources (as before).

> Is this supposed once every time your kernel changes or can this be run
> every time during boot?

I'm not sure to understand your question.

You can consider vboxbuild == dkms install vboxhost/4.1.18. (you can
use dkms autoinstall for short). So it's supposed to be run like
vboxbuild.

Adding dkms into your DAEMONS will ensure that needed modules will be
builded (for the running kernel) and loaded at startup.

If you reboot after vbox upgrade, your new modules will be compiled
for your kernel and loaded.
After a kernel upgrade you can wait until your reboot to have module
builded and loaded.

But if you want upgrade without reboot, you should:
kill virtualbox
dkms autoinstall (old vboxbuild)
rmmod vbox*
modprode vbox*
rerun virtualbox

> Are there systemd unit files for this?
Not yet. Patch welcomed.

--
Sébastien "Seblu" Luttringer
www.seblu.net

On Mon, Jul 23, 2012 at 9:04 AM, Sébastien Luttringer <seblu@seblu.net> wrote:
> On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch <karol@babioch.de> wrote:
>> Hi,
>>
>> Am 23.07.2012 02:01, schrieb Sébastien Luttringer:
>>> You will be able to build your virtualbox modules by running
>>> $ dkms install vboxhost/4.1.18
>>> or you can let dkms rc script compile/install/load your modules with
>>> $ rc.d start dkms
>
> To be clear
>
> You can still use virtualbox-modules to have your module pre-compiled
> for the arch kernel.
> If you have a custom kernel or want compile yourself your modules your
> can use virtualbox-sources (as before).

My current practice is to use my own simple wrapper script to call
vboxbuild $KERNEL to rebuild for all my currently installed kernels.
Will this be possible with dkms install? Come to think of this, would
dkms then be a hard dep for virtualbox?

If no to Q1, then could I just save a copy of the currently working
vboxbuild and continue to use that? I used to have my own script (its
probably backed up somewhere) for doing this, but vboxbuild was just
easier to use.

Sébastien Luttringer <seblu@seblu.net> on Mon, 2012/07/23 03:04:
> On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch <karol@babioch.de> wrote:
> > Are there systemd unit files for this?
>
> Not yet. Patch welcomed.

There are, please take a look at AUR package dkms-systemd.
--
main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++]
putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

On Mon, Jul 23, 2012 at 3:29 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
> On Mon, Jul 23, 2012 at 9:04 AM, Sébastien Luttringer <seblu@seblu.net> wrote:
>> On Mon, Jul 23, 2012 at 2:17 AM, Karol Babioch <karol@babioch.de> wrote:
>>> Am 23.07.2012 02:01, schrieb Sébastien Luttringer:
> My current practice is to use my own simple wrapper script to call
> vboxbuild $KERNEL to rebuild for all my currently installed kernels.
> Will this be possible with dkms install?

You can build/install script for a custom kernel version with something like
$ dkms install vbhoxhost/4.1.18 -k $KERNEL

You can also let dkms rc script do it for you at boot.

> Come to think of this, would dkms then be a hard dep for virtualbox?

dkms become an hard dep for virtualbox-source (and
virtualbox-archlinux-source). You can still use virtualbox-modules.

> could I just save a copy of the currently working vboxbuild and continue to use that?
For a time probably. However, there is some bug reports open which
will not be fixed.

> I used to have my own script (its
> probably backed up somewhere) for doing this, but vboxbuild was just
> easier to use.
This change is soft and can open new way of handling custom modules.

Take a look at dkms, it's a non-upstream modules manager. You can use
it to build/install/load _all_ your custom modules with "dkms
autoinstall".

--
Sébastien "Seblu" Luttringer
www.seblu.net

On 07/23/2012 06:11 AM, Sébastien Luttringer wrote:
>> Come to think of this, would dkms then be a hard dep for virtualbox?
> dkms become an hard dep for virtualbox-source (and
> virtualbox-archlinux-source). You can still use virtualbox-modules.
>

What about for those using virtualbox-bin and virtualbox-ext-oracle for AUR? I
attempted to build the virtualbox-ext-oracle package which pulled in as
dependencies:

virtualbox 4.1.18-2
virtualbox-modules 4.1.18-4

Neither were wanted. Does this new dependency requirement need to be fixed in
the AUR packages so that virtualbox-ext-oracle does not automatically pull in
the Arch versions?

--
David C. Rankin, J.D.,P.E.

On Mon, Jul 23, 2012 at 8:28 PM, David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
> On 07/23/2012 06:11 AM, Sébastien Luttringer wrote:
>>> Come to think of this, would dkms then be a hard dep for virtualbox?
>> dkms become an hard dep for virtualbox-source (and
>> virtualbox-archlinux-source). You can still use virtualbox-modules.
>>
>
> What about for those using virtualbox-bin and virtualbox-ext-oracle for AUR?
As i said in comment in virtualbox-bin they are greatly encouraged to
move to virtualbox as there is no real difference. I will probably
drop support of virtualbox-bin soon.

> I attempted to build the virtualbox-ext-oracle package which pulled in as
> dependencies:
>
> virtualbox 4.1.18-2
> virtualbox-modules 4.1.18-4
>
> Neither were wanted. Does this new dependency requirement need to be fixed in
> the AUR packages so that virtualbox-ext-oracle does not automatically pull in
> the Arch versions?

Why neither were wanted? As far i see, virtualbox is needed by
virtualbox-ext-orable and virtualbox-modules is a dependency of the
virtualbox.

--
Sébastien "Seblu" Luttringer
www.seblu.net

Sébastien Luttringer <seblu@seblu.net> on Mon, 2012/07/23 02:01:
> Some changes will be introduced in the next package release of virtualbox.

This is when virtualbox 4.1.20 is released? Have not seen anything in the
testing repos yet.
--
main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++]
putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

On Tue, Jul 24, 2012 at 2:50 PM, Christian Hesse <list@eworm.de> wrote:
> Sébastien Luttringer <seblu@seblu.net> on Mon, 2012/07/23 02:01:
>> Some changes will be introduced in the next package release of virtualbox.
>
> This is when virtualbox 4.1.20 is released? Have not seen anything in the
> testing repos yet.
No, tonight or tomorow (CEST).

--
Sébastien "Seblu" Luttringer
www.seblu.net