Summary: | app-emulation/virtualbox{,-additions,-modules}-4.0.0 ebuild bump request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tman <cornicx> |
Component: | New packages | Assignee: | Patrick Lauer <patrick> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | 404errorqc, alex, axiator, bugsgentoo, canarauc, dschridde+gentoobugs, evan.teran, gef.kornflakes, hauschild.markus, hubertstar, jan, jeisom, jr.juiliano, kripton, krog.az, kronenpj, oeffentlicheszeug, polynomial-c, rafdev, retired_user, rjwynne42, sir_tuam, sven.koehler, swapon |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Updated ebuild for 4.0.0
updated asneeded patch Updated VNC patch fix dependency patch patch 3.2.12 -> 4.0.0 extpack ebuild. new virtualbox-extpack ebuild with oracle use flag. virtualbox-modules-4.0.0 virtualbox-ose-additions-4.0.0 |
Description
tman
2010-12-22 19:41:51 UTC
(In reply to comment #0) > This version is a major update. The following major new features were added: I do not think quoting the full changelog is necessary. Just link to the website instead. > * Reorganization of VirtualBox into a base package and Extension Packs; This probably requires reorganisation of the ebuilds, too. I assume that app-emulation/virtualbox-ose will become app-emulation/virtualbox and the non-free extensions will move into a separate package. I do not really have much time to work on this at the moment. So any help of volunteers is highly appreciated. FYI with 4.0 app-emulation/virtualbox-bin should be depreciated as the binaries are only gpl code. USB EHCI is implemented with an extension pack now, available on the virualbox website. Created attachment 257912 [details]
Updated ebuild for 4.0.0
This is an updated ebuild for virtualbox-ose. added a use flag for "doc" as it appears we weren't and still aren't installing them. added dependencies app-arch/makeself and doc? (
dev-texlive/texlive-basic
dev-texlive/texlive-latex
dev-texlive/texlive-latexrecommended
dev-texlive/texlive-latexextra
dev-texlive/texlive-fontsrecommended
dev-texlive/texlive-fontsextra
)
currently require 3 updated patches.
Created attachment 257914 [details, diff]
updated asneeded patch
Created attachment 257916 [details, diff]
Updated VNC patch
Created attachment 257919 [details, diff]
fix dependency patch
Sorry for additional noise. I'm a little new at this. Comments welcome. Do you also have an ebuild for the extension-pack? Created attachment 257932 [details, diff]
patch 3.2.12 -> 4.0.0
Ebuild looks good so far, changes are minimal.
I renamed the patches from virtualbox-ose-X-4.0.0.patch to virtualbox-ose-4.0.0-X.patch, as that seems to be the standard.
Attached is the patch from 3.2.12 to 4.0.0 for easier review.
Hi Jonathan. Thanks for the ebuild and the patches. I've looked at the ebuild and it looks quite good. I have some suggestions I've already implemented in my private overlay at https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ I'd like to rename the ebuild from app-emulation/virtualbox-ose to app-emulation/virtualbox as I am planning to remove app-emulation/virtualbox-bin once some 4.x version becomes stable. The makeself dependency and the makeself patch are IMHO not necessary. Simply patch the check for makeself away from the configure script. I don't see any reason why virtualbox should need makeself. A patch which removes the check can be found in my overlay. The asneeded patch doesn't work anymore when you use a compiler with forced asneeded (see http://www.gentoo.org/proj/en/qa/asneeded.xml section "Forced --as-needed"). I will ask some of our asneeded-gurus for help about this once the ebuild landed in portage. I'm still wondering if it's really worth requiring a user to install fully blown latex just for getting some documentation installed. I think it's a bit overkill but if there are many voices appearing which want to have that feature I can keep it of course. There is one problem with installing the renamed ebuild. Once installation finished you have to run "env-update" as root and then "source /etc/profile" as user because the VBOX_APP_HOME variable changed. Otherwise the new virtualbox won't start but just present some error message window. A reboot should do the same of course but we aren't using windows are we? ;) Keywords += InOverlay ? (s.g.o doesn't have the ebuild yet) Whoops, I wonder why my comment changed the bug status to RESOLVED FIXED. The bug will stay open until the ebuild is in portage. Well my overlay is no official one which can get added through layman easily (it's possible of course but not through a single "layman -a"). So I'd say leave the keyword for now. I figured out a problem: The ebuild as presented here automagically uses Java. What makes this worse is that it uses /usr/lib/jvm/java-6-sun/bin/javac as the path to javac, without ever checking the existence of that file. See VirtualBox-4.0.0_OSE/Config.kmk: # Add correct detection for you distro after the /usr/../java-6-sun line. (In reply to comment #14) > I figured out a problem: > The ebuild as presented here automagically uses Java. What makes this worse is > that it uses /usr/lib/jvm/java-6-sun/bin/javac as the path to javac, without > ever checking the existence of that file. > > See VirtualBox-4.0.0_OSE/Config.kmk: > # Add correct detection for you distro after the /usr/../java-6-sun line. Should be fixed in my overlay. *** Bug 349624 has been marked as a duplicate of this bug. *** *** Bug 349622 has been marked as a duplicate of this bug. *** *** Bug 349618 has been marked as a duplicate of this bug. *** *** Bug 349624 has been marked as a duplicate of this bug. *** The extpack is just a tar gz file with the extension .vbox-extpack. It extracts with the extension installer built in to with the one I submitted: /usr/lib/virtualbox-ose/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/ current contents: darwin.amd64/ darwin.x86/ linux.amd64/ linux.x86/ solaris.amd64/ solaris.x86/ win.amd64/ win.x86/ I don't think we need all of them, Just the linux. not sure how to unpack it from portage. Created attachment 257999 [details]
extpack ebuild.
(In reply to comment #21) > Created an attachment (id=257999) [details] > extpack ebuild. mkdir should be replaced with dodir, cp with dobin & friends. Thank you hubertstar. I've added a modified version of your ebuild to my overlay. As soon as I had some time to work on and test the virtualbox-guest-additions and the xf86-{input,video}-virtualbox packages I gonna add all ebuilds to portage. I was wondering about the naming of the extpack ebuild. As it is possible that others may come out with packs I was thinking either virtualbox-extpack-oracle or virtualbox-oracle-extpack. *** Bug 349746 has been marked as a duplicate of this bug. *** (In reply to comment #24) > I was wondering about the naming of the extpack ebuild. As it is possible that > others may come out with packs I was thinking either virtualbox-extpack-oracle > or virtualbox-oracle-extpack. > Good idea! virtualbox-extpack should be a meta-package, Install oracle extpack by enable use flag. I was uploaded the new virtualbox-extpack ebuild. Lars Wendler, please check it. sorry for my bad english. Created attachment 258153 [details]
new virtualbox-extpack ebuild with oracle use flag.
hubestar, you had the correct idea with creating a meta package for the extensions but as long as there's only one extensions package available a meta package simply makes no sense. As soon as there are more than one extensions available I gonna add a meta package. Meanwhile I will stick with virtualbox-extpack-oracle. (In reply to comment #26) > (In reply to comment #24) > > I was wondering about the naming of the extpack ebuild. As it is possible that > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > or virtualbox-oracle-extpack. > > > > Good idea! > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > use flag. This doesn't seem like the current gentoo way of doing it. IMHO, you should use the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, which are use-expanded. (In reply to comment #29) > (In reply to comment #26) > > (In reply to comment #24) > > > I was wondering about the naming of the extpack ebuild. As it is possible that > > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > > or virtualbox-oracle-extpack. > > > > > > > Good idea! > > > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > > use flag. > > This doesn't seem like the current gentoo way of doing it. IMHO, you should use > the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, > which are use-expanded. I don't see a reason to not do it the same way like it's done in media-plugins/gst-plugins-meta (via USE flags and not through another make.conf variable...). Once there are a big load of different extensions available we can still implement this. But currently it's just too early to do it this way. AFAIK there's still only the Oracle extension pack available. (In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #26) > > > (In reply to comment #24) > > > > I was wondering about the naming of the extpack ebuild. As it is possible that > > > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > > > or virtualbox-oracle-extpack. > > > > > > > > > > Good idea! > > > > > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > > > use flag. > > > > This doesn't seem like the current gentoo way of doing it. IMHO, you should use > > the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, > > which are use-expanded. > > I don't see a reason to not do it the same way like it's done in > media-plugins/gst-plugins-meta (via USE flags and not through another make.conf > variable...). All of the USE-flags state a certain feature or codec, or something like it. Well, or just think about why most of those USE_flags are global. But in contrast, already the first USE-flag in the ebuilds attached to this bug, is highly specific. If it was called "usb" instead of "oracle", that would probably be a better use-flag-way of doing things. (On the other hand, it's just usb 2.0 support) I would really vote for another make.conf variable - if that is needed at all. Similar to the xorg-drivers ebuild, for example (it only uses make.conf variables). > Once there are a big load of different extensions available we > can still implement this. But currently it's just too early to do it this way. > AFAIK there's still only the Oracle extension pack available. Sure. I wasn't asking for it to happen right now. Emerging the one extpack seperately is not a big deal. At this time, which file should to be tested ? virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ? (In reply to comment #32) > At this time, which file should to be tested ? > virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ? The ebuilds being in my overlay are the ones which will go into portage. FYI, I've planned to add the ebuilds p.masked before end of the year. Virtualbox should depend on cdrtools (requires mkisofs) Checking for mkisofs: ** mkisofs (variable MKISOFS) not found! (In reply to comment #34) > Virtualbox should depend on cdrtools (requires mkisofs) > > Checking for mkisofs: > ** mkisofs (variable MKISOFS) not found! This is simply another useless check which I now patched away. (In reply to comment #11) > I'd like to rename the ebuild from app-emulation/virtualbox-ose to > app-emulation/virtualbox as I am planning to remove > app-emulation/virtualbox-bin once some 4.x version becomes stable. That's bad news for me. I am running amd64 no-multilib on all of my systems, and virtualbox-bin is the only package I can merge because of virtualbox-ose using the 32-bit toolchain for building the guest additions (according to http://www.virtualbox.org/wiki/Linux%20build%20instructions). Will the new virtualbox-4.0.0 package still need 32-bit components? (In reply to comment #36) > (In reply to comment #11) > > I'd like to rename the ebuild from app-emulation/virtualbox-ose to > > app-emulation/virtualbox as I am planning to remove > > app-emulation/virtualbox-bin once some 4.x version becomes stable. > > That's bad news for me. I am running amd64 no-multilib on all of my systems, > and virtualbox-bin is the only package I can merge because of virtualbox-ose > using the 32-bit toolchain for building the guest additions (according to > http://www.virtualbox.org/wiki/Linux%20build%20instructions). > > Will the new virtualbox-4.0.0 package still need 32-bit components? Uh... I didn't take no-multilib users into account... sorry for that. I guess I will have to set up a no_multilib environment first to test this issue but I cannot do that before I return home from 27C3. If this is still true for vbox-4 the planned package rename cannot be done of course (although I really dislike maintenance of the -bin package as I don't use it on any of my systems). Seems like there will be no vbox-4 in portage before next year :-/ (In reply to comment #33) > (In reply to comment #32) > > At this time, which file should to be tested ? > > virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ? > > The ebuilds being in my overlay are the ones which will go into portage. > what is the name of the overlay? :-) https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ Is in the URL of this bug. You can extract only relevant part from overlay via: lftp -e "mirror --only-newer --verbose downloads/gentoo/poly-c_overlay/app-emulation/ ." http://www.fn-clan.de/ and use your local overlay or you can use the normal method: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && layman -a poly-c (In reply to comment #39) > https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ > Is in the URL of this bug. You can extract only relevant part from overlay via: > lftp -e "mirror --only-newer --verbose > downloads/gentoo/poly-c_overlay/app-emulation/ ." http://www.fn-clan.de/ and > use your local overlay or you can use the normal method: layman -o > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > layman -a poly-c > * Overlay "poly-c" does not exist. first method seems to work but I would prefer using layman to stay updated easily (In reply to comment #40) > * Overlay "poly-c" does not exist. > > first method seems to work but I would prefer using layman to stay updated > easily Didn't work for me neither (layman 1.4.1). I had to add the URL to the XML file to layman.cfg. Then it worked. (In reply to comment #40) > (In reply to comment #39) > > use your local overlay or you can use the normal method: layman -o > > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > > layman -a poly-c > > > > * Overlay "poly-c" does not exist. > > first method seems to work but I would prefer using layman to stay updated > easily According to the manpage of layman the command should look like this: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -a poly-c (In reply to comment #42) > (In reply to comment #40) > > (In reply to comment #39) > > > use your local overlay or you can use the normal method: layman -o > > > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > > > layman -a poly-c > > > > > > > * Overlay "poly-c" does not exist. > > > > first method seems to work but I would prefer using layman to stay updated > > easily > According to the manpage of layman the command should look like this: > layman -o > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -a > poly-c You're right. Seems like this has changed a bit in portage. But your given command still doesn't work as the -f option is missing. The full command looks like this: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -f -a poly-c (replace -a with -s if you want to re-sync the overlay) This might be a good opportunity to request addition of my overlay to the official list of overlays. Sorry for the inconveniences guys. I gonna try to sort this out as soon as possible. s/portage/layman/ (damn I need some sleep when 27C3 is over ;) I would like to see a bump of the virtualbox-bin ebuild (which would not include the expack). Up to know, I have QT-free system, and emergeing virtualbox 4.0 pulls in QT :-( btw ebuild working well and no problems so far :-) Works fine on my x86 box, too *** Bug 350214 has been marked as a duplicate of this bug. *** poly-c overlay is now officially available through layman (thanks to sping). By the way, chances are high that virtualbox-4.0.0 will go into portage as virtualbox-ose-4.0.0 and removeal of virtualbox-bin will be skipped for now (no guaranty that it won't go away anytime later). I know that this will impose some more trouble to all you brave testers out there but at least the no-multilib issue is important enough to not get rid of virtualbox-bin yet. What still bothers me is the naming of the extpack. I don't think "virtualbox-extpack-oracle" is appropriate. I'd rather prefer "virtualbox-extpack-puel". What do you guys think? IMHO a clean way to do that and stay consistent with the behaviour of the rest of the tree is to have a package name like 'virtualbox-extension-packs' and use the ACCEPT_LICENSE variable (e.g. ACCEPT_LICENSE="PUEL") to unmask the package. Btw, naming '-ose' makes no-sense because there is no proprietary/open versions anymore, the only things that remain closed are the extension modules. It doesn't hurt however. (In reply to comment #49) > What still bothers me is the naming of the extpack. I don't think > "virtualbox-extpack-oracle" is appropriate. I'd rather prefer > "virtualbox-extpack-puel". What do you guys think? Why should the license be part of the name? What if company XYZ releases another extpack under gpl, would that be called virtualbox-extpack-gpl rather than virtualbox-extpack-XYZ? What if multiple extpacks with the same license exist? Throwing in my very own opinion on the extpack naming, if you all don’t mind. The only thing that defines an extpack, as of now (and probably in the future as well), is its manufacturer, so that’s what should be part of the name. I started out by considering: N1. virtualbox-extpack-oracle N2. virtualbox-extpack-usb N3. virtualbox-extpack-puel N4. virtualbox-oracle-extpack Maybe in the future: F1. somebody else will come up with an alternative (maybe free) USB extpack; F2. Oracle’s own extpack will come to include other extensions (say, a virtual modem card); F3. an extpack will be released under multiple licenses. In the F1 case, we want to avoid collision over ”usb”, so N2 isn’t a viable option; N2 isn’t an option due to F2 too; due to F3, I’d also suggest against N3. So, the only remaining ones are N1 and N4; as a personal preference, I’d go for N1, but that’s just me of course; I’m sure others might prefer the brand+extpack order. Also, there’s nothing weird about having oracle in the package name; for a long time we’ve had www-browser/mozilla-firefox, so this isn’t anything new. I hope this helps solve the naming issue. *** Bug 350401 has been marked as a duplicate of this bug. *** Created attachment 258674 [details]
virtualbox-modules-4.0.0
Created attachment 258676 [details]
virtualbox-ose-additions-4.0.0
*** Bug 350852 has been marked as a duplicate of this bug. *** Alright gyus I've now added the following packages to the tree: app-emulation/virtualbox-4.0.0 app-emulation/virtualbox-bin-4.0.0 app-emulation/virtualbox-modules-4.0.0 app-emulation/virtualbox-additions-4.0.0 app-emulation/virtualbox-extpack-oracle-4.0.0 x11-drivers/xf86-input-virtualbox-4.0.0 x11-drivers/xf86-video-virtualbox-4.0.0 app-emulation/virtualbox-guest-additions-4.0.0 Thank you very much for all your suggestions and your brave testings :) If there are any problems with the new packages, please file new bugs (after you have looked that there wasn't already filed one for the problem you wanna report ;). As soon as there are other extpacks than the oracle one I gonna start working on a -meta package with USE_EXPAND. If you find extpacks not being in the tree, don't hesitate to report them via bugzilla. |