| Summary: | vmware: no reply to project status mail | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Gentoo VMWare Bug Squashers [disabled] <vmware+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | floppym, giuseppe, Manfred.Knick, orodruinlair, stefantalpalaru, whissi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Michał Górny
2017-08-12 06:54:32 UTC
I'm the only dev left in the vmware team, and it's so far down my priority list that I might as well leave. As long as noone else signs up I'd suggest we move the vmware packages to overlay-only. There they have active contributors, and I can occasionally help out keeping the ebuilds in shape. Let's keep the vmware project as contact point for the overlay and overlay bugs then though. To be honest, I don't see a major difference between nobody working on them here vs there ;-). Maybe you should try the 'up for grabs' route first, and maybe even drop them to maintainer-needed for some time to give people more incentive to just take them (proxied maintainers in particular). As for the contact point, do you mean the whole project or just the mail alias? I'm not a "dev" but I do occasionally try to help with the vmware ebuilds. Unfortunately, it is not always easy to find time to contribute. So I would like to say that it would be an overstatement to say that the project has "nobody working on it"... but it does seem to be a close approximation :-/. upstream vmware doesn't move THAT fast, most of the work seems to be in kernel support, which is not too bad at the moment. So far, it is outpacing stabilization of the kernel itself as far as I can tell. STATUS UPDATE: VMware Products have been removed from Main Portage Tree during Nov-2017. Further development has been relegated to [vmware] Overlay. Situation as of today, 30-Nov-2017: Workstation : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 634770 Player : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 639162 Modules : stable in [vmware] = 308.5.8 / released = 329.0.0 : Bug 634862 Tools : stable in [vmware] = 10.1.6 / released = 10.1.15 : Bug 634854 Vix : c.f. Bug 637030 Cli : c.f. Bug 637032 Looking at [vmware] git repository, esp. since spring 2016, Fabio Rossi has taken over to introduce updates, kernel patches etc.: Thank you, Fabio! In Workstatin 14.0 Bug 634770, Ștefan Talpalaru has ported an arch package, adopted and developed it to solid usable state: Thank you, Stefan! As documented therein [ https://bugs.gentoo.org/634770#c57 ] , I have thouroughly tested the resulting ebuild. Furtheron, thanks to permission granted by Andreas, I have pruned Gentoo Bugzilla from all the old stale OBSOLETE bugs smelling like (..) and - to the best of my knowledge - adapted the few left to current state. Result: Only 13 left - none of them "serious" - some (almost) ripe to be closed [ https://bugs.gentoo.org/buglist.cgi?quicksearch=vmware&list_id=3748566 ] Vmware-workstation-12.* will EOL soon : 2018 / 02 / 25 Afterwards, all versions before 14.0 will be unsupported and - being unsafe - should be pruned. NEEDED now: Developer's decision - on Proposal to obsolete Tools - on accepting Stefan's proposal into [vmware] Overlay [ https://bugs.gentoo.org/634770#c58 ] Thanks. (In reply to Manfred Knick from comment #4) > STATUS UPDATE: ... > [ https://bugs.gentoo.org/buglist.cgi?quicksearch=vmware&list_id=3748566 ] ADDENDUM: [ https://bugs.gentoo.org/buglist.cgi?quicksearch=open-vm-tools&list_id=3748962 ] (In reply to Manfred Knick from comment #4) > NEEDED now: > > Developer's decision > ... This dates from 2017-11-30 - <----- no answer in more than a year. Nor any activity in [vmware-overlay] either. The *official* overlay is a black (security) hole for years now. Current, up-to-date AND perfectly working: c.f. our Bugs - Bug 663670 and - Bug 671218 Proposal: 0.) Finally erase current content or [vmware-overlay] as a whole. 1.) Let's ask Stefan to - either maintain his ebuilds in [vmware-overlay] - or - preferred - integrate it into Main Portage Tree. There is no activity in the vmware-overlay because there is no need for the version included there (I have only a license for version 12.5 so I use and test only that). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/api.git/commit/?id=403e3525e57701b709867d5f9891ca4ebe63dfbf commit 403e3525e57701b709867d5f9891ca4ebe63dfbf Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-02-15 15:40:36 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-02-15 15:40:36 +0000 repositories: Remove vmware Unmaintained and reported to have security issues. Bug: https://bugs.gentoo.org/627666 Signed-off-by: Michał Górny <mgorny@gentoo.org> files/overlays/repositories.xml | 14 -------------- 1 file changed, 14 deletions(-) (In reply to Manfred Knick from comment #6) > - or - preferred - integrate it into Main Portage Tree. That's not possible, since I'm blacklisted by core Gentoo developers: https://github.com/gentoo/gentoo/pull/9357#issuecomment-413590230 Turns out I can't even be a proxy maintainer: https://github.com/gentoo/gentoo/pull/9360#issuecomment-425749283 Since nobody is preventing me from maintaining a personal public overlay, I'll keep doing that instead of wasting my time on the main Portage tree. (In reply to Fabio Rossi from comment #7) > ... no need ... ??? > (I have only a license for version 12.5 so I use and > test only that). Fabio, I deeply value all your work and all your contributions for years - but EOL and VMSA are meant to be taken seriously. Sorry for having to deeply disagree: That usage might be perfectly valid in your private case - but it is no excuse for not at least hard-masking severe security risks for more than a year, allowing others running into potential disaster, esp. under the cloak of a "Gentoo official" overlay. Kind regards Yours sincerely Manfred (In reply to comment #8) Michal, after closing OBSOLETE [vmware] bugs, only Bug 653196 was left dangling around, itself referencing "VMware Version 9" being defenitely EOL for years now, so I closed that as "NEEDINFO". QUESTION: What about sec-policy/selinux-vmware ? QUESTION: What about Project:VMware ? QUESTION: What about (currently empty) wiki.gentoo.org/wiki/VMware ? Concerning "the other direction", "from the inside": Mike Gilbert <floppym@gentoo.org> could be persuaded to prune app-emulation/open-vm-tools from outdated versions as well: . . . [ https://bugs.gentoo.org/647292#c11 ] @ Mike : Thank you very much! (In reply to Manfred Knick from comment #10) > (In reply to Fabio Rossi from comment #7) > > ... no need ... ??? > > (I have only a license for version 12.5 so I use and > > test only that). > Fabio, > > I deeply value all your work and all your contributions for years - > but EOL and VMSA are meant to be taken seriously. > > Sorry for having to deeply disagree: > That usage might be perfectly valid in your private case - > but it is no excuse for not at least hard-masking severe security risks > for more than a year, > allowing others running into potential disaster, > esp. under the cloak of a "Gentoo official" overlay. IMHO I would like to leave to the final user the decision to use or not to use a software, the important thing is that he/she is aware of what is doing. I am still using it, I keep maintaining that version (e.g. the modules are working with latest kernel 4.20.x) and I'll do until it will work on my system. Probably it would be a good idea to hard mask the software and add a warning for the user during pkg_setup() to stress about the EOL and VMSA stuff. Moreover a lot of software is in portage which has unsolved CVE (just look for CVE on bugzilla), even latest upstream version, why don't we remove everything? (In reply to Fabio Rossi from comment #13) > ... the important thing is that he/she is aware of what is > doing. ... > ... Probably it would be a good idea to hard mask the <-----! > software and add a warning for the user during pkg_setup() to stress about > the EOL and VMSA stuff. That's all I ever asked, for ~two years now, even before Bug 619398. May I kindly remind that it was me rejecting deletion right away? "Hard-mask, but keep in [VMWARE Overlay] ..." [https://bugs.gentoo.org/619398#c8] AFAICS, the latest productive maintenance dates back to 2017-11-17, concerning Bug 637922 and Bug 637948, containing your commits to the overlay. Multiple times I stressed being grateful to you, being the last one remaining. That ws shortly after vmware ebuilds had been removed from MPT. ! Since then, no active Gentoo Developer spent any time to help, ! although working ebuilds were readily provided, e.g. as attachments. Starting 2017-11-07, Ștefan Talpalaru joined in: [https://bugs.gentoo.org/634770#c17] and maintenance reliably continued using his overlay, always providing the current version shortly after release. In _every_ of the few cases I detected any problem, fixes were provided right away: typically, the update was bumped in less than an hour! Even for old enhancement requests dangling around, implementations have been provided: e.g. Bug 604426: "make vmware-modules optional" being key for using it as a pure bridgehead for plain vSphere Hypervisor installations. QUESTION 1: How long would it have taken to integrate those versions (~) into [vmware] overlay? HINT: I need less than a minute to cherry-pick from [stefantalpalaru] into my local overlay and digest before starting independent tests on a stable minimal installation. QUESTION 2: @ "Gentoo VMWare Bug Squashers" et al.: - What could be hindering / - what would be needed to re-enter this ebuild into MPT? Yes, I noticed comment 9 - but I decline to accept that some old animosities should reject the provision of an important product in Gentoo. Still prepared to support Yours respectfully Manfred I've finally went ahead and disbanded the project. |