[MIR] virtualbox

Bug #1605337 reported by Steve Langasek
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
virtualbox (Debian)
New
Unknown
virtualbox (Ubuntu)
Invalid
Undecided
Matthias Klose

Bug Description

[Availability]
Currently in multiverse. The host component has external build dependencies not in Ubuntu; the source package would need to be split to allow the guest pieces to go into main.

[Rationale]
The guest package should be pulled in for cloud images targeting the virtualbox environment (i.e. vagrant). As this is an official cloud image that's being produced, the packages should all be in main and supported.

[Security]

[Quality Assurance]

[Dependencies]

[Standards Compliance]

[Maintenance]
Package ownership TBD. It is likely this should be owned by either the Cloud team or the Server team.

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Just to make you aware, I already did the split and it is even currently waiting on trusty new queue
(the split was done because the guest packages needs to be rebuilt on top of the lts stack, but this is OT).

The question is: if you take over the maintenance, just please take it over on Debian too!
I really would like to avoid maintain a delta for such a huge and problematic package.

thanks

Steve Langasek (vorlon)
Changed in virtualbox (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1605337] Re: [MIR] virtualbox

Gianfranco, thanks for the feedback!

On Thu, Jul 21, 2016 at 05:49:03PM -0000, LocutusOfBorg wrote:
> Just to make you aware, I already did the split and it is even currently
> waiting on trusty new queue
> (the split was done because the guest packages needs to be rebuilt on top
> of the lts stack, but this is OT).

Ah, I hadn't noticed this - <aside> the SRU NEW queue often goes unnoticed,
please feel free to ping me or another member of the SRU team directly on
#ubuntu-release when you have packages there that need review </aside>

I see that there is split packaging there, but I don't see anything to
handle the splitting of the upstream orig.tar.gz for into free and non-free
parts, which would be a requirement for putting the virtualbox-guest source
in main. Have you looked into this at all? Perhaps if you even have an
analysis of which parts of the source would need to be split, that would
give us a head start on automating this split.

> The question is: if you take over the maintenance, just please take it
> over on Debian too! I really would like to avoid maintain a delta for
> such a huge and problematic package.

Seeing that you are an uploader of the virtualbox package in Debian, I was
indeed quite eager to talk with you about how this might work. Would you be
interested in having this split done in Debian, so that Debian could also
have the virtualbox guest components in main instead of contrib - and so
that this packaging could be kept in sync?

Please note that when I spoke above of cloud or server teams being
responsible for "maintenance", I meant it only in the sense of
Ubuntu-specific maintenance - SRU requirements, security updates, the
occasional temporal delta. They would not be committing to maintain the
package in Debian, and I am 100% in agreement that we should avoid a delta
here between Debian and Ubuntu.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Michael Terry (mterry)
Changed in virtualbox (Ubuntu):
assignee: nobody → Matthias Klose (doko)
Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Little update after a long conversation on irc with Oracle guys (with a big thanks to them).

To be clear, I always had in mind that we were using prebuilt BIOS binaries, but this seems to be *not the case.

Workflow.

many *.c files
Open Watcom

some asm files
yasm
BIOS

quoting upstream
"we have no other choice. there simply is no (debian conforming) open source compiler which can deal with x86 segmentation, which is absolutely vital for implementing a working BIOS"

irc conversation (at the begin I was looking to the wrong issue I admit)

<oracle> LocutusOfBorg: regarding the assembly BIOS, if you have an appropriate assembler on your system, to my limited knowledge the assembly BIOS should be build automatically, unless OpenWatcom is found.
<oracle> You said you failed to build the assembly BIOS. I believe that should happen automatically during the build if you have a suitable assembler installed.
<oracle> Looks like the configure file could do with fixing.
<oracle> And we should and don't check for yasm, but should use it if it is there. That is what needs fixing.
<LocutusOfBorg> so, if I understand correctly
<LocutusOfBorg> you check for watcom, and use the built one if no watcom is found
<LocutusOfBorg> but probably yasm is good too, even if the configure is not aware of that
<oracle> Right, but probably only used (that is the idea of Make after all) if no binary is found.
<LocutusOfBorg> and with rm src/VBox/Devices/PC/BIOS/VBoxBiosAlternative*
<LocutusOfBorg> I can see if it is correct your claim
<oracle> Wait...
<oracle> That is the assembly code you want to build.
<oracle> No idea where the binary is...
<LocutusOfBorg> "Auto Generated source file. Do not edit."
<oracle> There is probably some PcBiosBin file somewhere.
<LocutusOfBorg> it is written on that VBoxBiosAlternative files
<oracle> Sure, it is generated by OpenWatcom. But by us, not by you.
<LocutusOfBorg> this is the problem
<LocutusOfBorg> we can't generate that asm file I guess
<oracle> You can't generate the C files we feed to OpenWatcom. And you are free to ignore the message and use the assembly as your original source.
<oracle> A fork, so to speak.
<LocutusOfBorg> This package is not part of the Debian operating system.
<LocutusOfBorg> It is in the "contrib" area of the Debian archive because it requires a
<LocutusOfBorg> non-free compiler (Open Watcom) to build the BIOS.
<LocutusOfBorg> Upstream provides pre-built BIOS images which is used instead.
<LocutusOfBorg> this is what I get from debian/copyright, it has been done long time ago
<oracle> LocutusOfBorg: btw, there are no BIOS binaries in the vbox source tree. only the VBoxBiosAlternative.* files, which are used if you don't have OpenWatcom.

The question is:
are some autogenerated asm files "enough source files" to be considered part of Ubuntu main?

this is an example
https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/src/VBox/Devices/PC/BIOS/VBoxBiosAlternative.asm

that would save us a lot of effort in the split.

G.

Changed in virtualbox (Debian):
status: Unknown → New
Revision history for this message
Matthias Klose (doko) wrote :

the reference to the assembler file is not valid anymore. Would need an update.

If we don't have the source, then we could promote it to restricted, not to main.

Changed in virtualbox (Ubuntu):
assignee: Matthias Klose (doko) → nobody
assignee: nobody → Matthias Klose (doko)
Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

There has been not further update for too long, for now we consider it invalid.
Feel free to re-open if there is effort backing it up and motivation to bring it to main.

Changed in virtualbox (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.