Package Details: virtualbox-ext-oracle 5.1.2-1

Git Clone URL: https://aur.archlinux.org/virtualbox-ext-oracle.git (read-only)
Package Base: virtualbox-ext-oracle
Description: Oracle VM VirtualBox Extension Pack
Upstream URL: http://www.virtualbox.org/
Keywords: virtualbox
Licenses: custom:PUEL
Submitter: seblu
Maintainer: seblu
Last Packager: seblu
Votes: 1048
Popularity: 17.400219
First Submitted: 2010-12-24 16:48
Last Updated: 2016-07-27 22:46

Dependencies (2)

Required by (1)

Sources (1)

Latest Comments

eaglex commented on 2016-07-16 15:52

For the latest version, use:

pkgver=5.1.0
md5sums=('06c5c47fd1d21bf6701a2f3b2146c7e1')

pgoetz commented on 2016-07-16 10:22

rdesktop is woefully out of date. I would add remmina as an optional dependency and perhaps drop rdesktop altogether. There's also gnome-rdp, although I haven't tried it and don't know what state it's in.

grawity commented on 2016-07-07 05:22

I found the difference. Apparently having TAR_OPTIONS="--xattrs" in the environment causes tar to use a format different from the default.

perlsite commented on 2016-07-01 18:32

Well, as workaround just use the "Download snapshot", extract in /tmp/vbep
open the PKGBUILD and change to "pkgver=5.0.24" and "md5sums=('f576d8521e6315b507ae7daab495c1e6')" respectively.

Keep only PKGBUILD and virtualbox-ext-oracle.install files. Delete all the other inside /tmp/vbep

run:
makepkg

and then:

sudo pacman -U virtualbox-ext-oracle-5.0.24-1-any.pkg.tar

Done.

j1simon commented on 2016-06-29 19:09

Why this package in your repository (http://seblu.net/a/$repo/$arch) is outdated?

$ pacman -Sl seblu | grep virtualbox
seblu virtualbox-ext-oracle 5.0.20-1

seblu commented on 2016-06-14 20:35

I appreciate your comment but it works perfectly for me since years.

grawity commented on 2016-06-14 05:32

I appreciate the attempts to "shrink" the extpack file, but VirtualBox isn't actually able to import it after the repacking. (In fact I don't think it has worked in the last *year* or so.) The install process always fails with:

VBoxManage: error: RTVfsFsStrmNext failed: VERR_TAR_UNSUPPORTED_PAX_TYPE

It seems that VirtualBox only understands --format=gnu and --format=ustar, *not* the default 'pax' format. (The original file uses GNU tar format.)

Rainmaker commented on 2016-03-11 09:40

@seblu.
I am the current maintainer of virtualbox-bin in AUR.
As virtualbox-bin and virtualbox-ext-oracle are related (a newer version of virtualbox-bin without an updated virtualbox-ext-oracle will not work), may I suggest making eachother co-maintainer?

bartki commented on 2015-12-07 11:00

@mabra: 'fakeroot' is a member of the package group 'base-devel', which is a prerequisite for building packages. Therefore it is not necessary to specify it as a build dependency.

mabra commented on 2015-12-06 22:14

Dependeny to 'fakeroot' is wether checked nor mentioned!

thirtythreeforty commented on 2015-11-23 05:25

It is now actually out-of-date, as the newly-packaged VirtualBox 5.0.10 complains about the 5.0.8 extension pack.

Mikaela commented on 2015-09-18 14:06

Sorry for flagging out-of-date, pamac hadn't checked for updates and I missed the last updated time.

hugao commented on 2015-08-18 18:02

Oh right, I'm sorry I miss read it when pacman installed. Sorry my bad.

dkaylor commented on 2015-08-18 15:21

@hugao Not much point, virtualbox in community is still out-of-date. Although virtualbox-bin in aur is. But how many are using it? No votes.

hugao commented on 2015-08-18 11:08

@seblu can you update to 5.0.2?

Scimmia commented on 2015-08-18 00:33

fakeroot is part of base-devel, which is assumed to be installed at build time.

seblu commented on 2015-08-17 21:13

Is this a question?

mzimmerman commented on 2015-08-17 20:01

fakeroot required for build

dkaylor commented on 2015-07-17 07:40

Updating your own package? Because nothing has been updated here, and you're not the maintainer.

mbostwick commented on 2015-07-17 06:57

updating the package version to 5.0.0, and adding the new md5sum of the file.
Here is the new md5sum, 3aa4a320f7bf64ddfa02e86e51eb5038

hschletz commented on 2015-03-06 14:03

The PKGBUILD contains a misleading comment: "shrink uneeded cpuarch" should be "remove unneeded support for non-Linux OS".

ranger commented on 2014-12-14 00:24

@Glenster
I repeat: this package is not the guest additions, it is an extension pack package for the host and only for the host. Read the Description. It is needed by the host to provide usb support for the guest. You have to install this in your host-debian.

Anyway, if you have more questions we can help you at the forums.

seblu commented on 2014-12-13 23:13

yes, please ask for help on forums or mailing lists, not in AUR comments.

Glenster commented on 2014-12-13 23:00

@ranger: Archlinux is the guest, and that's where I need to install the guest additions, because I get a message from the guest as follows when I check the box in its settings (before starting the guest) to enable USB 2.0:

"On the USB page, USB 2.0 is currently enabled for this virtual machine. However, this requires the Oracle VM VirtualBox Extension Pack to be installed. Please install the Extension Pack from the VirtualBox download site. After this you will be able to re-enable USB 2.0. It will be disabled in the meantime unless you cancel the current settings changes."

@ Musikolo: Thanks for clearing up my misunderstandings. I have now built and installed the AUR and it seemed to give no errors. I then went back to the wiki and went through the steps there (https://wiki.archlinux.org/index.php/VirtualBox#Install_the_Guest_Additions). But at the end of it all I still get the error message above.

Any further ideas, anyone?

ranger commented on 2014-12-13 19:08

@Glenster, you have arch as guest in vbox right?
Then you don't need this package in archlinux, you have to install it in you host (Debian)

Musikolo commented on 2014-12-13 19:02

@Glenster
This is an AUR package. You have to build it yourself and then install it. More info at https://wiki.archlinux.org/index.php/AUR

In addition, please, use "pacman -Syu" instead of "pacman -Syy" to get full update of your system.

Glenster commented on 2014-12-13 18:56

Hello,

I'm a beginner with Archlinux. I have installed an Archlinux VM on Virtualbox running on Debian. The networking is working fine and I have run "pacman -Syy" and reinstalled pacman with "pacman -S pacman"

I located the package by searching on the term "virtualbox" at https://aur.archlinux.org/packages/

However, when I run "pacman -S virtualbox-ext-oracle" in the VM I get this error:

"error: target not found: virtualbox-ext-oracle"

Could someone tell me what I am doing wrong? Thank you.

barton commented on 2014-09-14 07:36

Indeed
depends=("virtualbox=$pkgver")
is required by Oracle:
Discussion on the Oracle boards [1] elicited this response:
"I can tell you that the extension pack *must* match the running version"

[1] https://forums.virtualbox.org/viewtopic.php?f=7&t=63636#p298928

barton commented on 2014-09-14 07:34

Indeed
depends=("virtualbox=$pkgver")
is required by Oracle:
Discussion on the Oracle boards elicited [url=https://forums.virtualbox.org/viewtopic.php?f=7&t=63636#p298928]this[url] response
[quote]I can tell you that the extension pack *must* match the running version[/quote]

barton commented on 2014-09-13 23:23

Very nice except for one thing:
depends=("virtualbox=$pkgver")
Without that install throws an error because I've downgraded my VB install due to "Virtualbox abort on startup" issue currently discussed in the users' forum.

blackhole commented on 2014-09-11 20:52

Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.3.16.vbox-extpack"
VBoxManage: error: VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='Helper version mismatch - expected 0x10002 got 0x10001'
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManager, interface IExtPackManager
VBoxManage: error: Context: "int handleExtPack(HandlerArg*)" at line 1143 of file VBoxManageMisc.cpp
error: command failed to execute correctly

dixi_minga commented on 2014-08-29 05:00

oh, sorry, my fault; I had a look in my Backups; I lost group membership one month ago because of removing and reinstalling virtualbox
I did not recognize it, because my USB-Devices were still listed in the USB Settings

sorry for the suspicion

seblu commented on 2014-08-29 02:17

How could you loose a group membership because of this package?

Fortunately we hunt duplicates on our spare time, my main mistake is to not have killed it quickly.

dixi_minga commented on 2014-08-29 01:34

Now it works, I lost my vboxusers group membership with the new package.
I know it's "only" AUR; but I'm not very happy, that the "Duplicate" was simply deleted.

seblu commented on 2014-08-29 00:37

@dixi_minga: It was removed as duplicate. Could you be a little more specific, why this one is not working for you?

dixi_minga commented on 2014-08-28 19:59

I cant find anymore the package virtualbox-extension-pack; this was the only one for me, which works ?

msx commented on 2014-08-19 09:46

Thanks for automating the install of the extension :)

hybrid commented on 2014-07-26 05:04

Well I don't particularly prefer building my packages myself. But I do if the package I want frustrates me - always pulling in an unnecessary and unwanted dependency counts as frustrating in my mind. So thank you for your tip with "makepkg -d" but I already figured out my way of creating the package the way I want it.
But what's up with that "That's damn faster"? My complaint is not about speed (but if it was I would ask as to why you are actually unpacking the extpack, then rm the created files and repacking it instead of for instance piping it throught tar and use the -X/--exclude switch or anything but actually decompressing, altering files and compressing again), my complaint is about keeping things simple and without unneeded stuff.
So far I still couldn't come up with a sigle scenario in which a user has successfully installed virtualbox yet would run into trouble with this package if it hadn't that -dkms makedep. And this is the only package I've come across that finds that "-dkms trick" necessary.
Really, I would like to understand in which case this trick is useful and why. But reducing build time is not a valid reasoning in a package like this in my mind.

Your next statement about eworm's package raises the question: What should be in charge of keeping track of packages and/or it's files? A distribution's package manager or should third party tools such as VBoxManage be trusted to manipulate files while wielding root privileges?
While that could actually be an interesting question it is too abstract for this comment section. And I understand that you're just trying to comply with virtualbox by letting vbox handle it's ext-pack-files, even though they're not tracked by the package manager. I can even accept that approach if that's the only official option given by vbox and if one is worried about things breaking in vbox if not installed the "official way".

But please give the idea of forcing dkms on the virtualbox package a second thought. Because as great as dkms can be for servers as questionable it's usefulness is for desktops and medium workstations and more importantly: There is still no way for pacman to keep track of files created through dkms. And there is no official vbox rule I am aware of that would force one to use virtualbox specifically with dkms. So no need to hurry into a technology that isn't yet fully worked through just because it's cool.
If however you as the maintainer deem dkms really necessary I feel like the virtualbox package would be the proper place to dep on dkms and not this pkg which only relies on vbox. And again, in that case I would like to know who that would be necessary for to force dkms on all users. Not to troll, just to learn.

Lastly just for the record (not a perfect example, but one I quickly came up with): For example the nvidia package deps on a specific linux-package version range just like the virtualbox package. Yet other packages like nvidia-utils or opencl-nvidia don't seem to be in need for a -dkms trick.
Also the nvidia package copies and tracks the module directly, bypassing the installation routine. Just one of many packages that deal with these issues that way.

best regards

hybrid commented on 2014-07-26 04:55

Well I don't particularly prefer building my packages myself. But I do if the package I want frustrates me - always pulling in an unnecessary and unwanted dependency counts as frustrating in my mind. So thank you for your tip with "makepkg -d" but I already figured out my way of creating the package I want it.
But what's up with that "That's damn faster"? My complaint is not about speed (but if it was I would ask as to why you are actually unpacking the extpack, then rm the created files and repacking it instead of for instance piping it throught tar and use the -X/--exclude switch or anything but actually decompressing, altering files and compressing again) it's about keeping things simple and without unneeded stuff. So far I still couldn't come up with a sigle scenario in which a user has successfully installed virtualbox yet would run into trouble with this package if it hadn't that -dkms makedep. And this is the only package I've come across that finds that "-dkms trick" necessary.
Really, I would like to understand in which case this trick is useful and why. But reducing build time is not a valid reasoning in a package like this in my mind.
Your next statement about eworm's package raises the question: What should be in charge of keeping track of packages and/or it's files? A distribution's package manager or should third party tools such as VBoxManage be trusted to manipulate files while wielding root privileges. While that could actually be an interesting question it is too abstract for this comment section.
And I understand that you're just trying to comply with virtualbox by letting vbox handle it's ext-pack-files, even though they're not tracked by the package manager. I can even accept that approach if that's the only official option given by vbox and if one is worried about things breaking in vbox if not installed the "official way".
But please give the idea of forcing dkms on the virtualbox package a second thought. Because as great as dkms can be for servers as questionably it is for desktops and medium workstations and more importantly: There is still no way for pacman to keep track of files created through dkms. And there is no official vbox rule I am aware of that would force one to use virtualbox specifically with dkms. So no need to hurry into a technology that isn't fully worked through just because it's cool.
If however you as the maintainer deem dkms really necessary I feel like the virtualbox package would be the proper place to dep on dkms and not this pkg which only relies on vbox. And again, in that case I would like to know who that would be necessary for to force dkms on all users. Not to troll, just to learn.

And just for the record (not a perfect example, but one I quickly came up with): For example the nvidia package deps on a specific linux-package version range just like the virtualbox package. Yet other packages like nvidia-utils or opencl-nvidia don't seem to see the need for a -dkms trick. Also the nvidia package copies and tracks the module directly, bypassing the installation routine. Just one of many packages that deal with these issues that way.

best regards

seblu commented on 2014-07-24 08:05

I will probably remove this dep soon, as virtualbox will dep on virtualbox-host-dkms.

Nonetheless, this package takes care of this, to reduce the build time in a chroot; If you prefer build your package with makepkg, I suggest you to use "makepkg -d" instead of creating your own package. That's damn faster.

eworm's package is a fork (or duplicate) which bypass the virtualbox official way for installing external modules., by dropping somes files directly inside the virtualobx directory.

hybrid commented on 2014-07-24 06:54

Honestly I fail to see the need of virtualbox-host-dkms makedeps too.
Correct me if I'm wrong/missing something, but you said you included it only so virtualbox-host-modules won't be triggered to pull the arch stock kernel.
But why would this package need to take care of this? Basically this package here tries to "fix" dependencies higher up in the dependency tree. And that part doesn't make a lot of sense to me.
Plus this is only the case if someone is using a non-stock kernel to which there is no adapted virtualbox-host-modules package but in that case they wouldn't be able to install virtualbox in the first place.
Even if there are such cases that require that "virtualbox-host-dkms trick" I (again, just my personal opinion, I may be wrong) would deem that a special and rare case that should better be treated in a special package, for example virtualbox-ext-oracle-dkms.
I was using this package for a long time but this in my (and I assume by far most scenarios) pointless dependency that's always pulled by this package led me to create my own pkgbuild maybe like two years ago when this -dkms shennanigans started. Just set up a new computer here and accidentally installed this package and was reminded of this issue here.

I see that this package here and eworm's https://aur.archlinux.org/pkgbase/virtualbox-extension-pack/ are coexisting for a little over a year now.
Maybe this package here should be renamed to something like virtualbox-ext-oracle-dkms?

colinkeenan commented on 2014-04-16 00:18

error: target not found: 4.3.10-1

seblu commented on 2014-03-27 15:53

build in a chroot is not an atypical way of building a package. All released packages should be build inside a chroot. Learn to use devtools to do accordingly. Btw it's a makedepends, not a depends of the package.
You can still use makepkg -d, if you want to avoid this deps during build.

seblu commented on 2014-03-27 15:51

build in a chroot is not an atypical way of building a package. All released packages should be build inside a chroot. Learn to use devtools to do accordingly. Btw it's a makedepends, not a depends of the package.

dhaines commented on 2014-03-27 15:01

If it's there for a particular atypical setup (building in chroot), should it be there in the AUR for general consumption? That seems to be adding unnecessary packages to a lot of people's machines when very few of them actually need them.

seblu commented on 2014-03-27 14:21

$ wget -qO- 'http://download.virtualbox.org/virtualbox/4.3.10/Oracle_VM_VirtualBox_Extension_Pack-4.3.10.vbox-extpack'|md5sum
25b70fa71d9320e2836b9be138457ee0 -

Good from my home. Bad from my office. There is probably a replication issue between Oracle mirrors. I already see that in the past. The md5sum is correct.

@djhaines: Right, it doesn't require it to build. But the virtualbox deps pull virtualbox-host-modules, which pull linux kernel. Putting this makedeps deps avoid a kernel to be fetched when I build the binary package in a chroot.

seblu commented on 2014-03-27 14:20

$ wget -qO- 'http://download.virtualbox.org/virtualbox/4.3.10/Oracle_VM_VirtualBox_Extension_Pack-4.3.10.vbox-extpack'|md5sum
25b70fa71d9320e2836b9be138457ee0 -

Good from my home. Bad from my office. There is probably a replication of the Oracle mirrors. I already see that in the past. The md5sum is correct.

@djhaines: Right, it doesn't require it to build. But the virtualbox deps pull virtualbox-host-modules, which pull linux kernel. Putting this makedeps deps avoid a kernel to be fetched when I build the binary package in a chroot.

dhaines commented on 2014-03-27 13:47

I'm pretty sure that this shouldn't require virtualbox-host-dkms to build. I note that the PKGBUILD states "use virtualbox-host-dkms dep to avoid to pull linux kernel in chroot", but that (A) doesn't make a lot of sense and (B) doesn't seem to be true, as I've commented out the makedepends and it still seems to work without any issues.

cyrxi commented on 2014-03-27 13:44

The md5sum on the VirtualBox website/in the PKGBUILD *is* correct, but it's for Oracle_VM_VirtualBox_Extension_Pack-4.3.10-93012.vbox-extpack (i.e. the last minute update) and not the Oracle_VM_VirtualBox_Extension_Pack-4.3.10.vbox-extpack version pulled down by the PKGBUILD.

vinadoros commented on 2014-03-27 12:40

Thanks MonkeyWrench32, your md5sum does work properly for installing the 4.3.10 extensions. I'm not sure why Virtualbox's website has posted the wrong md5sum...

patryk commented on 2014-03-27 12:38

please check checksums.

venom commented on 2014-03-27 09:54

Got the same error like MonkeyWrench32. Changing the md5sum worked for me too

seblu commented on 2014-03-27 09:27

https://www.virtualbox.org/download/hashes/4.3.10/MD5SUMS

MonkeyWrench32 commented on 2014-03-27 04:12

md5sum failed. Here is the correct one: ec0a3d2f9ea4a6f7041586bd21520a6a

seblu commented on 2014-02-26 21:09

You really should read the PKGBUILD file before makepkg it, AUR is wild place.

benjarobin commented on 2014-02-26 20:50

Why virtualbox-host-dkms is into makedepends. To build the package you don't need this package...

Scimmia commented on 2014-01-18 14:10

That makes it a pain to upgrade, you would have to uninstall and reinstall this package every time vbox is upgraded instead of just upgrading it when needed.

caleb commented on 2014-01-18 07:31

Please do add the exact version dependency so that upgrades of the main package prompt a conflict that we then know to go fix. Thanks.

depends=("virtualbox=${pkgver}")

swiftgeek commented on 2013-10-21 18:40

But do not bump pkgrel :D

stmc commented on 2013-10-21 18:29

add to pkgbuild:
depends=("virtualbox=${pkgver}")

kullfar commented on 2013-10-21 05:16

BTW, it can be fixed by explicit version in "Dependencies", can not it be?

Scimmia commented on 2013-10-21 02:13

@ngoonee, that's because this package was update to 4.3 while virtualbox in the repos is still 4.2.18. You shouldn't update this package until virtualbox itself is updated.

ngoonee commented on 2013-10-21 02:11

Get this error from post_install.

Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.3.0.vbox-extpack"
VBoxManage: error: VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='Helper version mismatch - expected 0x10001 got 0x10000'
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManager, interface IExtPackManager
VBoxManage: error: Context: "int handleExtPack(HandlerArg*)" at line 1126 of file VBoxManageMisc.cpp

FredBezies commented on 2013-10-15 16:54

Will be soon out of date, as VirtualBox 4.3.0 was released on 15 october : http://www.oracle.com/us/corporate/press/2033376

archlinuxomane commented on 2013-09-10 08:54

@reed1

What's your virtualbox version? Had the same error message, reason was that I had updated the ext-pack to 2.18 but virtualbox was still 2.16.

eworm commented on 2013-09-10 07:28

I do not get this, so I suppose you need to reboot or shutdown guests, reload the new host modules and then start the guests.

reed1 commented on 2013-09-10 01:33

@eworm

When I fired up a VM with USB Controller enabled, if I disable it the error disappear. It's not like that before, probably after I upgraded the kernel. I reinstalled virtualbox and this aur package, nothing works.. :(, I haven't restared my machine tho, can't restart now

~ ❯ VBoxManage list extpacks
Extension Packs: 1
Pack no. 0: Oracle VM VirtualBox Extension Pack
Version: 4.2.18
Revision: 88780
Edition:
Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E1000 support.
VRDE Module: VBoxVRDP
Usable: true
Why unusable:

reed1 commented on 2013-09-09 23:54

@eworm

When I fired up a VM with USB Controller enabled, if I disable it the error disappear. It's not like that before, probably after I upgraded the kernel. I reinstalled virtualbox and this aur package, nothing works.. :(, I haven't restared my machine tho, can't restart now

eworm commented on 2013-09-09 11:19

@reed1: You get this when doing what?

% VBoxManage list extpacks
Extension Packs: 1
Pack no. 0: Oracle VM VirtualBox Extension Pack
Version: 4.2.18
Revision: 88780
Edition:
Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E100 support.
VRDE Module: VBoxVRDP
Usable: true
Why unusable:

reed1 commented on 2013-09-09 10:52

I got verr_pdm_devhlpr3_version_mismatch :(

eworm commented on 2013-05-28 10:55

Sure this may end up in conflicts. But that is still broken design by Virtualbox.

Installing the files to /var/lib is not the right way either. Quoting the Filesystem Hierarchy Standard [0] about /var:

> /var contains variable data files. This includes spool directories and files,
> administrative and logging data, and transient and temporary files."

and about /var/lib:

> This hierarchy holds state information pertaining to an application or the
> system. State information is data that programs modify while they run, and
> that pertains to one specific host.

I think the right way would be to make Virtualbox install files to ~/.VirtualBox/ExtensionPacks, while still accepting packages installed globally by pacman to /usr/lib/virtualbox/ExtensionPacks.

[0] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

seblu commented on 2013-05-28 10:41

@eworm: Firefox is a good example. Packages providing extensions are installed globally (in /usr) and users one are installed in there home. Virtualbox install user extensions in /usr too, asking for super cow power and bypassing pacman.
So, removing and readding this extensions by Vbox GUI will create conflict with next vbox package update. Nothing new.

I started looking to define a new vbox extension path outside /usr (e.g: /var/lib/) to avoid all conflicts with pacman. w&s.

$ find /var/abs -name *install|wc -l
1506

techlive commented on 2013-05-28 08:27

I second @eworm, system-wide files should be managed by pacman, this is how Arch works.

eworm commented on 2013-05-24 06:33

I do not agree. I think my example is relevant and valid. Take whatever package you like, usually there is no install script run by pacman after general package installation.

Ok, back to firefox, it's a good example: A user can install extension. These extensions are installed on a per user basis, in user's home directory. I am fine with that.

Virtualbox extensions however are installed globally in a world readable directory in /usr. Thus I think the files should be managed by pacman.

About the different package... Well, I tried to contribute my changes to your packages. But it's all about choice: We do have a different point of view and I made it my way. Users now may choose what they prefer.

seblu commented on 2013-05-23 21:58

The install.sh provided as installer by firefox have the same purpose as pacman. Here we speak of a GUI provided by Virtualbox, after it's installation, to hot add (official or not) extensions into /usr or remove it without talking to pacman. Your example is not relevant.

I love the idea to have all files in /usr managed by pacman, so your argument is challenging. But allowing users to re-add/add/remove extensions by the virtualbox GUI is convenient and not in our hands.

I've the same logic in https://www.archlinux.org/packages/community/x86_64/virtualbox-ext-vnc/.

Your prompt pushing of a different package is _not_ smart and don't help to improve things for both packages.

eworm commented on 2013-05-23 20:02

As Sébastien does not like the idea... I've uploaded my own package to AUR:
https://aur.archlinux.org/packages/virtualbox-extension-pack/

eworm commented on 2013-05-23 19:40

I see it does. But that is not really a good reason to rely on that mechanism, no? Or did you download firefox.tar.gz and ran some crappy install.sh script?

pacman should know about every single file installed to /usr, everything else is just broken.

seblu commented on 2013-05-23 19:35

Yes Christian, it was already discussed in the past.

In short, vbox use its own install/removal mechanism for extensions.

eworm commented on 2013-05-23 19:29

Any good reason why this package just owns a binary blob and copies some files outside package management while installing?

I have a new PKGBUILD that handles that the right way:
http://pastebin.com/0K2pJh3Z

seblu commented on 2013-03-10 18:04

Look in previous comments.

graysky commented on 2013-03-10 16:45

virtualbox-ext-oracle.install directs pacman to run the following on install:

VBoxManage extpack install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-${1%%-*}.vbox-extpack" >/dev/null

In doing so, modifications outside of the package itself are done to the filesystem. Is there a way to have VBoxManage redirect the output of that command to the $pkgdir/right/path thus keeping these files owned by the package?

lpapp commented on 2013-02-17 14:29

@Marcel_K: then perhaps someone should check.

seblu commented on 2013-01-27 16:20

When reinstall, it remove old extpack before install again. So I don't see why you have an issue.

rafaelff commented on 2013-01-27 02:51

In the install file, please modify the post_upgrade() adding the '--replace' flag to VBoxManage extpack install, otherwise it might failt to install the extension in VBox.

Message:
"VBoxManage: error: Extension pack 'Oracle VM VirtualBox Extension Pack' is already installed. In case of a reinstallation, please uninstall it first"

Steps to reproduce:
- installed this package
- reinstalled (as it didn't show up before in VBox) - removed '> /dev/null' to get error message.

Marcel_K commented on 2012-11-15 13:11

You may not redistribute this binary, as you can read in several earlier comments.

lpapp commented on 2012-11-15 12:46

Why is this core package not in the community repository? This is essential for proper USB working!

spider-mario commented on 2012-09-23 14:10

Oh, OK. Sorry.

Anonymous comment on 2012-09-22 07:58

@spider-mario: It's not about AUR, it's about [community].

spider-mario commented on 2012-09-22 07:47

I think it’s OK. The binaries are not redistributed, the PKGBUILD just automates the download from Oracle’s website, so they can still “keep track of how many people are downloading these binaries”.

Anonymous comment on 2012-09-18 14:15

@muflone: Please, read the comments, at least the ones from yesterday.

Muflone commented on 2012-09-18 13:45

Please update this package to the version 4.2.0

felixonmars commented on 2012-09-17 17:23

Oh, sorry to hear that :(

seblu commented on 2012-09-17 17:21

https://www.virtualbox.org/wiki/Licensing_FAQ

Look into section 7. It's dead.

seblu commented on 2012-09-17 17:15

We must ask permission to Oracle. I will look into this.

felixonmars commented on 2012-09-17 17:07

Is there any chance that this package grants by InnoTek Systemberatung GmbH to re-distribute from binary?

seblu commented on 2012-09-17 17:00

I will update this package when I will move virtualbox 4.2 out of testing.

graysky commented on 2012-09-17 16:58

Yeah, the official package which !=4.2 when I posted that.

felixonmars commented on 2012-09-17 16:47

Arch package is out.

seblu commented on 2012-09-17 16:25

He means official arch package!

allspark commented on 2012-09-17 15:06

what 'ARCH' packages do you mean?

http://download.virtualbox.org/virtualbox/4.2.0/Oracle_VM_VirtualBox_Extension_Pack-4.2.0-80737.vbox-extpack and virtualbox-bin are version 4.2

graysky commented on 2012-09-17 07:23

Not out-of-date until the ARCH packages for 4.2 are released.

Anonymous comment on 2012-09-14 13:14

http://ix.io/2ZO New PKGBUILD.

mrohnstock commented on 2012-08-07 09:23

ok, found my issue... forget it.

mrohnstock commented on 2012-08-07 09:21

build works, but can't install the package:

0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.1.18.vbox-extpack": The installer failed with exit code 1: VBoxExtPackHelperApp: error: The owner is not root: '/usr/lib'

seblu commented on 2012-04-04 08:28

@la_poigne: this let me detect new version and push a pkg upgrade in case.

la_poigne commented on 2012-04-03 16:59

The build version changed.
There are a symlink on the download page, so you don't need to specify the build version on the pkgbuild.
http://pastebin.com/iDZ3Afmj

seblu commented on 2012-04-03 15:32

http://pastebin.com/bxS8GQq9

kfgz commented on 2012-04-03 15:20

LC_ALL=C wget -O /dev/null "${source[0]}"

--2012-04-03 17:19:56-- http://download.virtualbox.org/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack
Resolving download.virtualbox.org... 137.254.16.69
Connecting to download.virtualbox.org|137.254.16.69|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://dlc.sun.com.edgesuite.net/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack [following]
--2012-04-03 17:19:57-- http://dlc.sun.com.edgesuite.net/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack
Resolving dlc.sun.com.edgesuite.net... 90.84.55.24, 90.84.55.83
Connecting to dlc.sun.com.edgesuite.net|90.84.55.24|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2012-04-03 17:19:57 ERROR 404: Not Found.

seblu commented on 2012-04-03 15:03

$ source PKGBUILD
$ wget -O /dev/null "${source[0]}"
--2012-04-03 17:02:33-- http://download.virtualbox.org/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack
Resolving download.virtualbox.org... 137.254.16.69
Connecting to download.virtualbox.org|137.254.16.69|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://dlc.sun.com.edgesuite.net/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack [following]
--2012-04-03 17:02:33-- http://dlc.sun.com.edgesuite.net/virtualbox/4.1.12/Oracle_VM_VirtualBox_Extension_Pack-4.1.12-77218.vbox-extpack
Resolving dlc.sun.com.edgesuite.net... 2.22.48.82, 2.22.48.136
Connecting to dlc.sun.com.edgesuite.net|2.22.48.82|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10062879 (9,6M) [application/x-virtualbox-vbox-extpack]
Saving to: `/dev/null'

100%[==========================================================================================================================================================================>] 10 062 879 19,6M/s in 0,5s

2012-04-03 17:02:34 (19,6 MB/s) - `/dev/null' saved [10062879/10062879]

kfgz commented on 2012-04-03 14:25

Download link is broken.

Anonymous comment on 2012-02-27 02:27

@DasFox:
> is this really necessary?
Yes, it is, and it is common in Linux and Unix. This way it can be used by every user. See the file permissions which are 644 (rw-r--r--). Every package gets installed by pacman this way. The home directory (~) is only meant for the user's own files like documents, music files, etc., and configurations. Btw., it's not installed under /root, but under / (also called "root directory").

> I forgot to mention at the end of the install in the terminal there should be a message telling the end-user where the extension is installed.
Totally not necessary, since this is not done with any other package and not common. If you want to know, what's installed where, run pacman -Ql <package name>.

I'd suggest reading and learning a bit more about the Linux basics, particularly about the file permissions, the Filesystem Hierarchy Standard (FHS) and package managers. The Wiki and the Forums are a good start, or even better some other websites and books about Linux.

Anonymous comment on 2012-02-27 02:01

I forgot to mention at the end of the install in the terminal there should be a message telling the end-user where the extension is installed. I was not aware of what /path it had been installed to, then we have to go digging in /var/lib/pacman/local to see where it's at in the pkg directory files...


THANKS

Anonymous comment on 2012-02-27 01:58

Hi,

As an end-user you can download the extenstion pack from Oracle, place it in your $HOME and install this, but since this is being installed into /usr/share it is owned by root and you need to run Virtualbox as root to install this, is this really necessary?

I'm not sure if all of this is common on other distros with it in a /root path owned by root, needing to be installed by root...

Also is /usr/share really the correct path for this? If it's ok to place it in this path owned by root then it should at least be given 'wheel' permissions so a user in group wheel can access it as a user not root?


THANKS

Anonymous comment on 2011-11-06 18:22

@mikers: How many times do I need to explain this? No versioned dependencies in AUR! Not even in makedepends! Keep your system regularly up-to-date and you won't have any problems. Otherwise edit the PKGBUILD locally by yourself.

And makedepends are not needed here, because there doesn't need to be built anything. Makedepends is for packages which are needed to build (compile) a package, but not for running this software, and which can be uninstalled after the package is built. This is not the case here. And if it was the case, what sense does it make to build a package with a newer version than the installed one? It makes no sense, because the package could then easily be broken.

And usually there is a reason why a package is not moved from [testing] to the stable repos.

@seblu: It would be nice if you would follow the stable repos and not [testing] resp. [community-testing].

chungy commented on 2011-11-06 17:17

Hey I know this is a rather discussed topic already, but what if this package had a makedepends=("virtualbox-$pkgver")? As the current version of VirtualBox has still not left testing in the main repositories, this will at least stop automated AUR wrappers from building this package, but it will not prevent upgrading either virtualbox or virtualbox-ext-oracle.

trusktr commented on 2011-10-14 12:09

I don't really know about that, but you seem to have a good point cyberpatrol.

Anonymous comment on 2011-07-20 10:25

No, please, not again a versioned dependency! This just causes big trouble with updating the system like discussed very often.

@monson: Arch Linux is a rolling release distro which has only one (the newest) version of each package in the repos. So it can be assumed that everybody has the newest version installed. Keep your system up-to-date and regularly run `pacman -Syu` or even better `yaourt -Syua` and you won't have any problems with that. With versioned dependencies you regularly need to manually uninstall this package to be able to run a `pacman -Syu` and manuall reinstall it afterwards.

monson commented on 2011-07-20 04:15

To be convenient to most people, I think it's better to modify to depends=("virtualbox=$pkgver"),
as the "virtualbox_bin" PKGBUILD already provides=("virtualbox=${pkgver}").

monson commented on 2011-07-20 02:48

To be convenient to most people, I think it's better to modify to depends=("virtualbox=$pkgver"),
as the "virtualbox_bin" PKGBUILD already provides=("virtualbox=${pkgver}").

monson commented on 2011-07-20 02:29

Please modify the depends to

depends=("virtualbox=$pkgver")

mukhametshin commented on 2011-07-19 23:23

qs9rx:
Now virtualbox_bin is already in repo. Just try to update virtualbox_bin first, and this package hereafter, it should work. However I'm sure seblu will fix it soon.

seblu commented on 2011-07-19 18:35

yes it did not check. You can find why in previous comment.

qs9rx commented on 2011-07-19 14:42

Proceed with installation? [Y/n]
(1/1) checking package integrity [#########################################################] 100%
(1/1) checking for file conflicts [#########################################################] 100%
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
(1/1) upgrading virtualbox-ext-oracle [#########################################################] 100%
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.1.0.vbox-extpack": VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=00000000 ErrInfo='VirtualBox version mismatch - expected 4.1 got 4.0'
error: command failed to execute correctly

---------------------------------------------
pacman -Qs gives me
local/virtualbox 4.0.12-1
local/virtualbox-additions 4.0.12-1
local/virtualbox-ext-oracle 4.1.0-1

So I guess it did not check for the needed vbox version which is not in the repositories yet (just released today).

Det commented on 2011-06-25 20:20

By the way, what cyberpatrol said about all the files in "$startdir" automatically being symlinked into "$srcdir" was not entirely accurate. Only the ones listed in the source=() section are (thus passing the integrity check first).

seblu commented on 2011-06-25 12:22

We are on the same wavelength. I was not sure about deprecation (will be removed) of startdir even though I had no doubt of the fact that it was necessary to use ${src/pkg}dir. it may seem paradoxical but not.
I proposed a patch on pacman-dev, to update man page of PKGBUILD.

Det commented on 2011-06-25 03:27

I'm not quite picking up what you're saying but what I _think_ you mean is that you checked the pacman/makepkg source code and there was a cd command to 'src', am I right? You also said that "$startdir" was being used there (even though it's otherwise deprecated), which would makes this all really simple and easy, since: "$startdir/src" = "$srcdir" (and "$startdir/pkg" = "$pkgdir").

But again, if you meant something else then please do enlighten me.

seblu commented on 2011-06-25 01:02

@det: i test this when i've done my first package, but before your suggestion i never take time to read makepkg source how it was done and if my conclusions was correct. Proof against the experience...

Det commented on 2011-06-25 00:30

And a simple 'pwd' in the beginning of a(ny) function is a simple way to find out the default build directory (even package() functions are executed from "$srcdir").

seblu commented on 2011-06-24 20:41

ok thx.

Anonymous comment on 2011-06-24 20:24

$startdir is deprecated. In case of doubt the wiki and every developer who has said that several times on the mailing lists are right. And, btw., every file in $startdir is symlinked to $srcdir. So there's no need to use $startdir, no matter if it's deprecated or not.

seblu commented on 2011-06-24 19:38

I will clean this in next release.

About deprecation of startdir, this is not written in man page of PKGBUILD, but it's written on the wiki (who is right?). In source code, startdir is used, so i don't think it's deprecated! But here, I agree it's unnecessary.
About build()/package()/whatever() functions, i don't find any informations in manual or wiki about where it should when function is run. In source code, there is a cd in src before every function call.

Thanks for the suggestions!

Det commented on 2011-06-24 19:07

Great, yet simple package. Just one suggestion.

You don't need to define "$srcdir" or "$startdir" (deprecated) in the beginning of the build()/package()/whatever() function since that's where the commands are already being executed in ("$srcdir"). After that you don't need the quotes there either.

adlaiff6 commented on 2011-06-17 00:28

Yes, I still get those.

someonerandom: do you have /usr on a separate partition?

adlaiff6 commented on 2011-06-17 00:27

Yes, I still get those.

seblu commented on 2011-05-20 09:09

do you have those messages if you run as root:
VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
VBoxManage extpack install /usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.0.8.vbox-extpack

someonerandom commented on 2011-05-20 07:13

@adlaiff6: same for me!

adlaiff6 commented on 2011-05-17 07:39

resolving dependencies...
looking for inter-conflicts...

Targets (1): virtualbox-ext-oracle-4.0.8-1

Total Download Size: 0.00 MB
Total Installed Size: 3.39 MB

Proceed with installation? [Y/n]
(1/1) checking package integrity [########################################] 100%
(1/1) checking for file conflicts [########################################] 100%
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack": The installer failed with exit code 1: VBoxExtPackHelperApp: error: Failed to rename the extension pack directory: VERR_NOT_SAME_DEVICE
VBoxManage: error: rcExit=1
error: command failed to execute correctly
(1/1) upgrading virtualbox-ext-oracle [########################################] 100%
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.0.8.vbox-extpack": Extension pack 'Oracle VM VirtualBox Extension Pack' is already installed. In case of a reinstallation, please uninstall it first
error: command failed to execute correctly

uberGeek commented on 2011-03-23 01:49

@seblu: you're welcome!

uberGeek commented on 2011-03-23 01:48

@cyberpatrol: Your welcome.

seblu commented on 2011-02-17 20:07

@cyberpatrol: thanks!

Anonymous comment on 2011-02-17 19:38

@seblu: It is out-of-date. Version 4.0.4 is out.

seblu commented on 2011-02-17 19:24

@uberGeek: please don't mark this package out-of-date until it's not out-of-date!

emphire commented on 2011-02-07 16:08

@vigilandy: If you would like to change the dependencies on your own machine, try customizepkg-new. It automates changes to packages and integrates with yaourt.

vigilandy commented on 2011-02-07 11:55

@cyberpatrol: I see, thanks for the clarification.

Anonymous comment on 2011-02-07 11:17

@vigilandy: Qt should not be a dependency of this package, because this package depends on virtualbox from [community] and qt is already an optional dependency of virtualbox. It's an optdepend, because it's only necessary if the VirtualBox GUI is used.

vigilandy commented on 2011-02-07 05:45

I was getting the following error when running:

"VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: libQtCore.so.4: cannot open shared object file: No such file or directory"

I resolved it by installing the qt package. Shouldn't this be a dependency?

alphazo commented on 2011-01-30 22:02

For info, it crashes the same way with VirtualBox 4.0.2-4 from [Community-Testing].

seblu commented on 2011-01-26 18:02

@alphazo: i've a blue sceen with a ehci issue. i will add some comment on you br

seblu commented on 2011-01-26 15:01

you should see something like this with lsusb.

[root@archibal ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet

alphazo commented on 2011-01-26 07:26

But what if my USB HD webcam only works in EHCI mode. How can I check that EHCI is running fine?
VBox log only mentions EHCI one time at the beginning.

00:00:02.380 [/PDM/Devices/VBoxEhci/] (level 3)
00:00:02.380 Path <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/VBoxEhciR3.so" (cb=97)
00:00:02.380 R0SearchPath <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64" (cb=83)
00:00:02.380 RCSearchPath <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64" (cb=83)
00:00:02.380
00:00:02.380 [/PDM/Drivers/] (level 2)

When I connect a USB flash drive, VBox log says:
00:00:31.944 VUSB: attached '00007f1a34046ad0[proxy 090c:1000]' to port 1
00:00:31.948 OHCI: USB Operational
00:00:41.907 PCNet#0: Init: ss32=1 GCRDRA=0x0669d420[64] GCTDRA=0x0669d020[64]
00:00:42.945 PIT: mode=2 count=0x4ad (1197) - 996.81 Hz (ch=0)
00:01:09.988 Switching Gl mode on
00:01:10.024 Switching Gl mode off
00:01:10.385 Switching Gl mode on
00:01:10.422 Switching Gl mode off
00:05:53.113 USB: Successfully reset device pProxyDev=00007f1a34046ad0[proxy 090c:1000]

And when I connect the webcam I get:
00:05:53.880 OHCI: USB Suspended
00:06:17.830 VUSB: attached '00007f1a35ac3f60[proxy 06f8:300b]' to port 1
00:06:17.836 OHCI: USB Operational

None of them say EHCI. Is this normal?

seblu commented on 2011-01-25 23:45

module add only USB 2.0 (EHCI). without you have only UHCI and OHCI.
If you vbox crash without the module, it' seems to be a bug relative to virtuabox himself and not only its extension.

alphazo commented on 2011-01-25 23:20

It crashes the same way when I remove this package. Now webcam is expected to run at USB High-Speed. I noticed that when I install the virtualbox-ext-oracle I do see it under Extension but I no longer see EHCI settings under USB. Is this normal? How do I check that ext-oracle is fully working? BTW, I run 2.6.37 from [Testing]

alphazo commented on 2011-01-25 23:19

It crashes the same way when I remove this package. Now webcam is expected to run at USB High-Speed. I noticed that when I install the virtualbox-ext-oracle I do see it under Extension but I no longer see EHCI settings under USB. Is this normal? How do I check that ext-oracle is fully working?

alphazo commented on 2011-01-25 23:17

It crashes the same when I remove this package. Now webcam is expected to run at USB High-Speed. I noticed when I install the virtualbox-ext-oracle I do see it under Extension but I no longer see EHCI settings under USB. Is this normal?

seblu commented on 2011-01-25 22:30

VirtualBox crash if you remove this package?

alphazo commented on 2011-01-25 22:23

Don't know if my bug is related to this package but VirtualBox crashes badly when connecting USB webcams. See my report on Oracle bug tracker: http://www.virtualbox.org/ticket/8184

seblu commented on 2011-01-22 15:44

@cyberpatrol: currently i follow virtualbox_bin.

Anonymous comment on 2011-01-22 15:35

@seblu: Thanks. But, please, follow the stable virtualbox in [community], not in [community-testing], if it goes there first.
@Musikolo: pacman -Syu does the job without the need of a versioned dependency in an AUR package.

Musikolo commented on 2011-01-22 09:37

@seblu: I don't know whether it will help to find a hybrid solution, but wouldn't be enough by doing this?

depends=("virtualbox" >= 4)

Please, let me know if I'm wrong, but with this, the problem of upgrading with pacman -Syu should be fix and, also, pleople having virtualbox-3.x will be force to upgrade to 4.x.

Best regards!

seblu commented on 2011-01-22 01:48

@cyberpatrol, lrm: you're right. i will fix.

lrm commented on 2011-01-22 01:29

I'm with cyberpatrol. The versioned dependency just causes trouble and doesn't save anyone from anything. If someone updates their aur without doing pacman -Syu first then they deserve what they get, IMO :).

Anonymous comment on 2011-01-21 22:49

@seblu: Your impression is wrong. But I know the reason for this updating issue. I explained it quite detailed, and I've tested it, at least with the =. I don't know, yet, if I can downgrade both packages and test it again. But I don't think that this is necessary, if you read Mektub's and shivmeister's latest comments. Shivmeister is, btw., an Arch Linux developer. So I guess you can believe him, if you don't believe me.

Mektub has already tried it with >= and he had to remove the version number, because it didn't work for him with >=. And shivmeister explained to you why versioned dependencies are sometimes needed and why they should be avoided otherwise. And you just need to think logical. Then you will see why also >= can't work.

And keep in mind the issue is not updating only this package with yaourt. The issue is a complete system update with pacman -Syu or clyde -Syua which is simply not possible. These are facts and not my ego.

And another point: If you really want to become a TU then you should know that.

seblu commented on 2011-01-21 22:01

@cyberpatrol: long time ago? This package have 3 weeks... Please be serious.
I don't test every cases. I invite you to try and tell me if their is issues.

I have the impression that you want us to do it your way and not otherwise.

Anonymous comment on 2011-01-21 21:31

@seblu: Did you test it with pacman -Syu when virtualbox in [community] was updated, too? Just updating virtualbox-ext-oracle with yaourt could bring wrong results, which don't help with this issue. This issue has to do with circular dependencies.

Btw., it's long ago that virtualbox was updated from 3 to 4 and this update is/was done by pacman -Syu, too. So there's definitely no need anymore for this versioned dependency. It was infact not needed before to get a correct transition from 3 to 4, just because of the rolling release and because there's only one version of a package in the repos. It can be expected from Arch users to update their systems regularly and not only update one single package from AUR.

So it's definitely the best to remove these versioned dependency, and it's btw. Arch plolicy. Believe me.

seblu commented on 2011-01-21 20:59

so,

i make a test with a fake 4.0.3 version of virtualbox...

rwolf ~/scm/archrep/virtualbox_bin $ yaourt -U virtualbox_bin-4.0.3-1-x86_64.pkg.tar.xz
resolving dependencies...
looking for inter-conflicts...

Targets (1): virtualbox_bin-4.0.3-1

Total Download Size: 0,00 MB
Total Installed Size: 129,80 MB

Proceed with installation? [Y/n]
checking package integrity...
(1/1) checking for file conflicts [########################################################################################] 100%
(1/1) upgrading virtualbox_bin [########################################################################################] 100%
:: Unloading VirtualBox kernel modules [BUSY] [DONE]
:: Recompiling VirtualBox kernel modules [BUSY] [DONE]
:: Reloading VirtualBox kernel modules [BUSY] [DONE]

seblu commented on 2011-01-21 20:55

ok i will test

Mektub commented on 2011-01-21 20:41

@seblu:>= does not work. Thats the line I changed to be able to update.

seblu commented on 2011-01-21 19:07

@cyberpatrol: firstly i make this version condition to avoid users from 3.x to setup this extentions before update in virtualbox 4.0, because install script needs a virtualbox version >= 4 ! So a good versioning is at least >=4 not without any version condition.

Regarding release rolling schema, you're right, we have only one version at the same time in repository. But we also have to manage correclty transition between our version. Your initial request was about that.
So, have one package at a time, is not synonymous with "forget everything about the past". Why do you want to change this dependency? It's free and without pain and escape someone with version 3.x to mistaken using this package? I think it's wiser to keep it for now.

About >=, i hope to not be false. In next virtualbox update, pacman allow setup of this new version, because there is no conflict. virtualbox-ext-oracle need a version more recent than itself. Same things for this package update.

Time is a chatterbox who speak without being questioned. W&S

Anonymous comment on 2011-01-21 18:48

@seblu: Sorry, I must have missed this change, but I don't think that >= works, because the previous installed version is <=. So >= has at least theoretically the same effect than =. Why don't you just remove this? Arch Linux is a rolling release distro with only one version of a package in the repos. I repeat myself.

seblu commented on 2011-01-21 18:36

@cyberpatrol: As you can see, the first time you speek about this dependency issue, i updated the package and changing = to >=.
Reading later comments, this decision seems to be fair and take in consideration the both point of view. This is why i left >=.

So what's wrong with >=?
On new version of virtualbox package, you will be able to update virtualbox without removing previous virtualbox-ext-oracle.
On new version of virtualbox-ext-oracle, you need to have new virtualbox version setup before (what we want).

Anonymous comment on 2011-01-21 18:18

@seblu: The versioned dependency:
depends=("virtualbox>=$pkgver") => depends=("virtualbox")

seblu commented on 2011-01-21 16:19

@mektub: Which changement? What's wrong?

Mektub commented on 2011-01-21 14:20


I had to change PKGBUILD to be able to update my system. I don't know if I did it the right way.
Someone more knowledgeable should take a look at it, something is wrong with the packaging of virtualbox-ext-oracle.

lrm commented on 2011-01-20 18:56

Is there a specific reason I have to uninstall this package to update my system? I'm no expert, but that is very annoying. If there is a good reason then so be it, but I'd love to know what it is. Thanks!

schivmeister commented on 2011-01-20 13:20

And why in the world does this have a versioned dependency again? Please get rid of that. It does not make any sense and is _wrong_, unless someone shows us why. Arch is rolling-release and there is only one version of a package at a time. We use versioned dependencies for people upgrading from CD installations that may be older than supported.

juanmah commented on 2011-01-20 06:48

I endorse what @cyberpatrol says, and I think that a solution shall to be found, because the current behaviour of this package is annoying.

But I don't think that this is a versioning problem, because of my case is that I have virtualbox_bin, and not virtualbox, and there is a conflict.

A fast check at https://wiki.archlinux.org/index.php/Virtualbox suggest that we have to use virtualbox in community, and if you want extras we have to install this package. Am I right?, because I am not sure of this.

If i is true, it is necessary to INFORM users what they have to do, because the normal procedure of pacman is broken. And this is not because users do not know what to do, but to save time.

Anonymous comment on 2011-01-19 22:59

I do comprehend the most obvious. I have explained it.

Anonymous comment on 2011-01-19 22:52

I will not waste any more of my precious time, if you can't comprehend the most obvious.

Anonymous comment on 2011-01-19 20:33

@wantilles: But this doesn't mean, that these versioned dependencies are necessary in this case. The most important reason why these versioned dependencies need urgently be removed from this package is simply because the system can't be updated by pacman -Syu. This is reason enough to remove them. It's really not nice to always force the user to first uninstall this package and then, after the system update, reinstall this package again. The other reason is simply because if this package is updated every user should also update virtualbox. You can expect that every user, at least every Arch user, knows that he has to do so. The best is updating the whole system regularly and not only a single package. Updating a single package can always break something. See Gentoo's revdep-rebuild, which should be run after every update. And because there's only one version of a package in the repos it simply isn't necessary to have versioned dependencies in this package. It's simply not necessary. If someone updates only this package without using his eyes and brain then it's his own fault and not a wrong dependency.

It's different on Gentoo where several older versions are kept in the portage tree and where a new package version can be put into a different slot. In this case versioned dependencies are useful and necessary, but not on Arch Linux.

Anonymous comment on 2011-01-19 19:32

Version dependencies are discouraged.

That does not mean that if they are NECESSARY, you should not use them.

And yes, each virtualbox extension REQUIRES a base virtualbox base package OF THE EXACT SAME VERSION - NOT something OLDER.

Anonymous comment on 2011-01-19 19:30

I never said that it does not happen.

I said that it is the wrong reason to change correct deps -> to wrong deps -> in a binary distro like Arch.

If we were a source distro, like Gentoo, then yes, it would be a correct reason to do something about this.

Anonymous comment on 2011-01-19 17:26

@wantilles: I am right, because I tested it. pacman -Syu doesn't work and pacman -Syud is the worst thing you can do if it's possible anyway. And versioned dependencies are discouraged anyway. Arch Linux is not Gentoo where you can put different versions into different slots. Arch Linux has only one version of one package in the repos. And if a package is updated then it can be assumed that the dependencies are updated, too. So you can assume that everybody has the latest versions installed. If someone only updates virtualbox-ext-oracle without updating virtualbox, he's on his own.

Anonymous comment on 2011-01-19 17:16

Cyberpatrol is wrong.

You never change correct dependencies, to wrong ones, because the package has not been built yet.

You can built the package with -d switch.

Anonymous comment on 2011-01-19 06:01

@cyberpatrol:you are right. i meet the problem too. have to delete virtualbox-ext-oracle and then packer -Syu.

Anonymous comment on 2011-01-19 03:03

It would be nice if you would change the line
depends=("virtualbox=$pkgver")
to
depends=("virtualbox")

It's because the system can't be updated neither with clyde -Syua nor with pacman -Syu, because it always says that virtualbox-ext-oracle requires virtualbox=4.0.0 even if the latest version in the repos is 4.0.2. And Arch Linux is a rolling release system with only one, the latest, version in the repos. So it can be assumed, that everybody regularly runs a full system update and has the latest version installed. If not, it's the user's problem.

The problem is that virtualbox can't be updated from 4.0.0 to 4.0.2 because virtualbox-ext-oracle 4.0.0 is installed and requires virtualbox 4.0.0. So pacman can't update virtualbox and can't resolve the dependency. And virtualbox-ext-oracle can't be updated from 4.0.0 to 4.0.2 because virtualbox 4.0.0 is still installed and can't be updated to 4.0.2. This problem might not appear if virtualbox-ext-oracle would be in [extra], too.

Anonymous comment on 2011-01-18 14:09

I agree seblu, it's all very strange. That line in my fstab is from about three years ago, so I don't doubt that it's outdated now. But none of the threads in the vbox forums were of any use in solving the greyed out usb devices problem. Their mods just repeat to install the extension pack and make user a member of the vboxusers group, reboot and then usb should work. It's only when checking the groups that I noticed the ID change.

Anyway, thank you for maintaining the virtualbox packages. They are very useful to me and I would be lost without them.

seblu commented on 2011-01-18 10:56

strange. i believe new virtualbox use /dev/bus/usb instead of /proc/bus/usb.

Anonymous comment on 2011-01-18 08:14

I changed from AUR package virtualbox_bin to the community virtualbox and installed this package too. My usb devices were all greyed out after the change. The answer was to make myself a member of the vboxusers group again & to alter a line my fstab (old vbox had its group as 110, new verson as devgid=108)

none /proc/bus/usb usbfs devgid=108,devmode=0664 0 0

All worked fine on reboot.

seblu commented on 2011-01-08 20:08

Please also note, there is an issue with Qt librairies and community packages. virtualbox_bin is not affected.
So currently, virtualbox_bin is a workaround for peoples which are affected by this issue.

seblu commented on 2011-01-08 20:06

@cyberpatrol: I're wrong. I maintain the two packages. Believe me.

Anonymous comment on 2011-01-08 19:39

@seblu: I haven't read jarryson's PKGBUILD yet, but virtualbox_ext_oracle has nothing to do with virtualbox_bin, because these extensions are already included in virtualbox_bin as far as I know. So if I'm right virtualbox_ext_oracle is only needed with virtualbox from [community].

seblu commented on 2011-01-08 15:57

@jarryson
i will add strip option in next release. Thanks.

But, i have 2 issues with you PKGBUILD:
1- You suppose VirtualBox store its Extension in /usr/lib/virtualbox/ExtensionPacks/. But if you use virtualbox_bin package, path is /opt/VirtualBox/ExtensionPacks. This is difficult (impossible?) to know at packaging time the right path.
2- Why do you want to code again something when it's done geniously by software developer and there is no difference?

jarryson commented on 2011-01-08 15:38

Maybe extract the content will be better?

PKGBUILD: http://aur.pastebin.com/X4fbVN8J

Anonymous comment on 2011-01-06 21:08

missing deps " -> virtualbox=4.0.0 " ?

seblu commented on 2010-12-27 20:45

@alphazo: this comment still has no connection with this package...

alphazo commented on 2010-12-27 15:48

USB EHCI has been fixed in virtualbox 4.0.0-3. No longer need to manually add the udev rule.

seblu commented on 2010-12-27 00:10

@alphazo: This bug is not on oracle extensions (which add support of USB 2.0). USB 1.O is bundled without extension pack. USB devices are greyed without pack installed.
So this should be fixed in upstream package.

alphazo commented on 2010-12-26 23:51

Apparently virtualbox package from community repo will have the fix tomorrow.

alphazo commented on 2010-12-26 23:22

Ok so I got it working by using the udev rule found here https://bugs.archlinux.org/task/22221

For some reasons my user was not part of vboxusers group. I added it to it and USB was back (after rebooing with the above udev rule).

This should be added to the PKGBUILD.

alphazo commented on 2010-12-26 22:58

Looks like there is a missing udev rule in order to get USB host working
I tried to manually install the rule but still no luck. https://bugs.archlinux.org/task/22221

I also tried to use the udev rule found in virtualbox-sun PKGBUILD from AUR but no luck as well.

alphazo commented on 2010-12-26 21:11

I'm moving from Virtualbox 3.x (PUEL edition from AUR that supports USB) to 4.x (Base version (GPL) from Community and this package (PUEL) for additional support such as USB). My 3.x was fully working including USB host.
I've uninstalled Vbox 3.x and installed the following packages:
- virtualbox 4.0.0-2
- virtualbox-additions 4.0.0-1
- virtualbox-ext-oracle 4.0.0-2
Extension pack shows up in Virtualbox extension manager (USB host). I've also installed guest additions and verified that USB host was enabled under VM's configuration. My XP VM starts but I'm unable to select any of my USB devices (everything is grayed out). Is there any additional step to go through in order to get access to USB devices?

seblu commented on 2010-12-26 00:30

@mektub: No you are right! I'm sorry. After checking conscientiously, this message appears if vbox modules are not loaded. Fixed in -2. Thanks!

seblu commented on 2010-12-26 00:29

@mektub: thanks!

Mektub commented on 2010-12-26 00:25

Sorry,seblu, my bad...

Mektub

seblu commented on 2010-12-26 00:08

@mektub: This message is probably shown by another (probably virtualbox-ose or virtualbox_bin)

Mektub commented on 2010-12-25 21:47

After installing it says:

... Please recompile the kernel module and install it by

sudo /etc/init.d/vboxdrv setup

I think it should be /etc/rc.d/vboxdrv setup

seblu commented on 2010-12-25 14:57

@cryptocrack: will be done on next update
@ngoonee: yes it should.

ngoonee commented on 2010-12-24 22:50

@maintainer - so if we have the repo version of virtualbox4 and this package it completely replaces virtualbox_bin?

lfleischer commented on 2010-12-24 22:35

You should use `install -D` instead of mkdir(1) and cp(1) in the package() function.