Re: [gentoo-dev] Gentoo on VMWare - few ideas
Coincidence, installed Gentoo on a WinXP VMWare today and I use VMWare it at work.The only difference is that you don't need all the livecd drivers.Maybe an doc for the specific installation is sufficient with a working kernel-config just like in the gentoo-wiki but an official one. Oh yeah... and submit to VMWare also. There's a lot of docs about other distros in the main site [1] but no Gentoo there. The vmware-linux-tools is not up2date. I'll try to update the 5.0.0 ebuild and put it in bugs.g.oI'm using workstation 5.5.1 and it as 32bits and 64bits binaries/drivers.[1]: http://www.vmware.com/support/guestnotes/doc/On 3/5/06, Jose Alberto Suarez Lopez [EMAIL PROTECTED] wrote: I think that it's a nice idea.Maybe 2 versions: with X and w/o X just to reduce the space needed. Can be great to try gentoo inside any other linux or win machine. Canbe great too to try new systems ebuilds or to test things.El 04/03/2006, a las 8:32, Kalin KOZHUHAROV escribió: Hi all, I finally get to test the new 2006.0 LiveCD and the new installer (GUI version). It certainly has many kinks to be ironed out, but it is a great new start! I am now waiting for the install on a vmware-workstation-5.5 while reading what Google had to say about VMWare Gentoo... A few quick ideas: 1. Wouldn't be great if we have a pre-built VMWare machine that gets released with every new Gentoo release? The problems: Somebody has to do it: /me is trying, somebody else already using it? As it will be pre-installed Gentoo, the many options that the installer provides will be already pre-shoosen... However Gentoo is flexible enough to change them after that. Somebody has to host it: not sure how does this fit inside Gentoo mirrors, it will probably be the size of a LiveCD Somebody has to support it: how many devs and how many skilled users are there for gentoo on vmware? It depends on commercial closed-source software... Ir is it useful with VMPlayer only? Yeah, and the HOWTO [1] has to be updated... [1] http://gentoo-wiki.com/ HOWTO_Install_Gentoo_on_VMware_in_Windows_NT/2K/XP What is it worth: For windoze people it will be a great way to experience/play with Gentoo For the challengers, using hardmasked-and-brake-my-gentoo ebuilds in a nice snadbox will be easy Just a quick preview of the next release or any other feature bug 2. As a result of idea 1 and using the info from [2] the Gentoo community can get lots of fame and some people can get some money. [2] http://www.vmware.com/vmtn/appliances/challenge/ Kalin. -- |[ ~~ ]| +- http://ThinRope.net/ -+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list--gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Just another portage enhancement idea...
Well, there's enotice.http://dev.gentoo.org/~eldad/On 10/11/05, Carlos Silva
[EMAIL PROTECTED] wrote:On Tue, 2005-10-11 at 09:18 -0400, Dave Nebinger wrote:
This is probably the fifth time at least that I've been bitten by this... Portage is great in that it manages compiles for a bulk of applications (including dependencies) in one fell swoop.
Yesterday I emerged gnome - that was it, just gnome, and it took care of the whole thing soup to nuts.Wahoo, and kudos to all of you who put in the work. But here's my issue...In emerging one of the 101 packages missing on my
system for gnome, a little blurb flew buy that should have caught my attention, a message posted in the pkg_postinst() message indicating what I should do now that my installation has completed.
That's well and good, but as it was one of only 101 other packages, that message quickly gets lost in the shuffle. So here's the enhancement: have portage collect all of these kinds of messages
and display them after all of the emerging has completed. So here's my proposed enhancement: Before the call to pkg_postinst(), set a flag that causes einfo/ewarn/etc. to tee the output generated by the ebuild
to /var/log/portage_postinst.log (or something configurable in make.conf, whatever).Preface the first generated line with the ${P} so we know what it's related to.After the pkg_postinst() method completes, clear the flag
and other emerges can carry on as they need to. Had this kind of thing been in place, after emerging 101 packages I could go to the postinst log and see everything that I had to do, including the little
blurb that I had missed before. Yes, I know folks are going to say that you can enable portage logging and look for messages that need to be taken care of.But I just emerged 101 new packages, have many emerge -ud worlds, etc. resulting in almost 2000 files
out there in /var/log/portage.Talk about the needle in the haystack, there's not even some specific keywords I could grep on to hit on the relevant information. Understandably I don't know what you all will say about this.It seems like a
great idea to me, and wouldn't appear to come with all the political issues that the 'extending the ebuild meta data' or some other issues that have come up recently. But I'll leave it to the rest of you to decide...
I could be wrong, and if i am, someone from the portage team to correctme, but i think this will come in the next major version of the portagealong with the tool elog.--Carlos r3pek Silva
Gentoo Developer (kernel/amd64/mobile-phone)-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux)iD8DBQBDS8hAttk+BQds59QRAmA1AJ9B5k3jYh6CnYKdO1hb4oLXBOzjggCffaLDuNSPq9C8xxPpG4bBiH42VC0=
=mWCg-END PGP SIGNATURE-
Re: [gentoo-dev] Commercial software in portage
Hi everybody,If it's commercial, the company in question should (and must) allow an ebuild for is product, like what happens with rpms and other packages. Adding commercial ebuilds to portage is like tainting the kernel with binary drivers. Maybe a better solution comes with gensync? If companies want ebuilds, sure. They go to the commercial portage. Hell, even put a price on maintaining those ebuilds.Remember that are a lot of people that don't want to use that kind of software. There are people that doesn't have even xorg and have to sync all the ebuilds from portage. On 9/21/05, Matthew Marlowe [EMAIL PROTECTED] wrote: We could add a license, called commercial into the tree.This license would look like the following.I would definitly support adding commercial as a license group as part of GLEP23 implementation.As part of adding any new commercial license to the tree, developers would haveto add the license to the commercial group.While this will break completely interactive ebuilds until GLEP23 is fully implemented, a user can add the license to make.conf in an ACCEPT_LICENSE variable, to keep portage from asking again.We wouldnt break anything (hopefully) if we just do this as I specified above.Also, I'm wondering if we truly need check_license in ebuilds.Instead, we could require that all licenses listed in the commercial group be manually added tothe ACCEPT_LICENSES line /etc/make.conf before emerging.If the licensewasnt added, emerge would stop and ask the user to add the license manually. Therefore, the user would be explicitely indicating their approval of the license byadding it.Implementation could be as simple as ACCEPT_LICENSES not allowing+commercial to be defined.It makes no sense, or at least we shouldnt encourage someone to say they agree to all commercial licenses so easily anyway.The defaultportage ACCEPT_LICENSE would be -commercial.MattM--gentoo-dev@gentoo.org mailing list
