Debian Templates: dpkg: warning: version '3.18.17-7.pvops.qubes.x86_64' has bad syntax: invalid character in revision number

[adrelanos]

sudo apt-get install --no-install-recommends virtualbox

...
Setting up virtualbox-dkms (4.3.32-dfsg-1+deb8u2) ...
Loading new virtualbox-4.3.32 DKMS files...
First Installation: checking all kernels...
dpkg: warning: version '*-*' has bad syntax: version number does not start with digit
dpkg: warning: version '3.18.17-7.pvops.qubes.x86_64' has bad syntax: invalid character in revision number
It is likely that 3.18.17-7.pvops.qubes.x86_64 belongs to a chroot's host
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.
Setting up virtualbox (4.3.32-dfsg-1+deb8u2) ...
...

Dunno if we care about this and if it's likely to cause follow up issues.

[marmarek]

Virtualbox probably will not work without its kernel modules, and we
don't have kernel headers (of kernel provided from dom0) packaged for
Debian.
But take a look here:
https://www.qubes-os.org/doc/managing-vm-kernel/#tocAnchor-1-3

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Virtualbox probably will not work without its kernel modules, and we
don't have kernel headers (of kernel provided from dom0) packaged for
Debian.
But take a look here:
https://www.qubes-os.org/doc/managing-vm-kernel/#tocAnchor-1-3

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Yes. Nevermind if VirtualBox will work or not. It works good enough for my purposes. (Using vboxmanage to build Non-Qubes-Whonix inside Qubes Debian AppVMs.) [VirtualBox installation using dkms is only one trigger here.]

This report is specific to dkms only.

dpkg: warning: version '-' has bad syntax: version number does not start with digit
dpkg: warning: version '3.18.17-7.pvops.qubes.x86_64' has bad syntax: invalid character in revision number

[adrelanos]

Yes. Nevermind if VirtualBox will work or not. It works good enough for my purposes. (Using vboxmanage to build Non-Qubes-Whonix inside Qubes Debian AppVMs.) [VirtualBox installation using dkms is only one trigger here.]

This report is specific to dkms only.

dpkg: warning: version '-' has bad syntax: version number does not start with digit
dpkg: warning: version '3.18.17-7.pvops.qubes.x86_64' has bad syntax: invalid character in revision number

[marmarek]

Ok, is it an issue? IOW do you need to build that kernel modules to use vboxmanage? Or maybe it is just a warning, which can be ignored (and this issue closed)?

[marmarek]

Ok, is it an issue? IOW do you need to build that kernel modules to use vboxmanage? Or maybe it is just a warning, which can be ignored (and this issue closed)?

[adrelanos]

IOW do you need to build that kernel modules to use vboxmanage?

No. It works fine without it. [However, this warning can be shown totally unrelated to VirtualBox. On any dpkg thing.]

Or maybe it is just a warning, which can be ignored (and this issue closed)?

Probably just a warning. The only thing it does is causing confusion. But for now apparently not breaking anything.

[adrelanos]

IOW do you need to build that kernel modules to use vboxmanage?

No. It works fine without it. [However, this warning can be shown totally unrelated to VirtualBox. On any dpkg thing.]

Or maybe it is just a warning, which can be ignored (and this issue closed)?

Probably just a warning. The only thing it does is causing confusion. But for now apparently not breaking anything.

[unman]

This is a standard warning, arising because the version contains an underscore, which is against Debian Policy. It won't break anything.
One could avoid it by generating kernel version using x86.64 instead.

[unman]

This is a standard warning, arising because the version contains an underscore, which is against Debian Policy. It won't break anything.
One could avoid it by generating kernel version using x86.64 instead.

[marmarek]

I don't believe we'll fix this in reasonable future. Can we close it as "wontfix", or @unman you want to work on this?

[marmarek]

I don't believe we'll fix this in reasonable future. Can we close it as "wontfix", or @unman you want to work on this?

[unman]

On Tue, Jun 07, 2016 at 04:43:56PM -0700, Marek Marczykowski-Górecki wrote:

I don't believe we'll fix this in reasonable future. Can we close it as "wontfix", or @unman you want to work on this?

I'll take a look - it should be pretty straightforward.

[unman]

On Tue, Jun 07, 2016 at 04:43:56PM -0700, Marek Marczykowski-Górecki wrote:

I don't believe we'll fix this in reasonable future. Can we close it as "wontfix", or @unman you want to work on this?

I'll take a look - it should be pretty straightforward.

[unman]

@marmarek
There's a trivial test in dkms.common to determine it's a Debian machine, and the inferred version contains "_".
One simple solution would be to name kernels in accord with Debian convention, replace x86_64 with amd64, which would look odd to Fedora eyes.
Other would be to close as "wontfix" - it's only a warning in Debian, doesn't affect the package install.

[unman]

@marmarek
There's a trivial test in dkms.common to determine it's a Debian machine, and the inferred version contains "_".
One simple solution would be to name kernels in accord with Debian convention, replace x86_64 with amd64, which would look odd to Fedora eyes.
Other would be to close as "wontfix" - it's only a warning in Debian, doesn't affect the package install.

[unman]

@andrewdavidwong Can you close this "Wont Fix" - it's a warning (only) that arises from different naming conventions between Fedora and Debian.

[unman]

@andrewdavidwong Can you close this "Wont Fix" - it's a warning (only) that arises from different naming conventions between Fedora and Debian.