Fails to emerge * Home for VM 'icedtea-bin-8' does not exist: /usr/lib/jvm//icedtea-bin-8 * Invalid System VM: icedtea-bin-8 Reproducible: Always Steps to Reproduce: 1. emerge www-client/chromium 2. 3. Actual Results: * Home for VM 'icedtea-bin-8' does not exist: /usr/lib/jvm//icedtea-bin-8 * Invalid System VM: icedtea-bin-8 Expected Results: Expected to emerge fine.
Created attachment 787130 [details] build log part 1 build log part 1
Created attachment 787133 [details] bulld log part 2 bulld log part 2 build log too big, even gzipped!
Created attachment 787136 [details] bulld log part 3 bulld log part 3
Created attachment 787139 [details] bulld log part 4 bulld log part 4
Created attachment 787142 [details] bulld log part 5 bulld log part 5
Please specify the correct MIME type when attaching files.
Please ensure you have a valid system Java VM selected (eselect java-vm show system).
Seems to me that every ebuild should check for dependencies before runing for 12 hours and failing. A simple check for "valid system Java VM" would save, me, and others a lot of time.
Under normal circumstances, the Java VM should not be in an invalid state. I don't think it makes sense to add a check to every ebuild that calls java. For example, we don't explicitly check to make sure you have a valid gcc profile selected in every ebuild that calls gcc.
(In reply to Mike Gilbert from comment #9) > Under normal circumstances, the Java VM should not be in an invalid state. I > don't think it makes sense to add a check to every ebuild that calls java. Your normal does not match my normal. > For example, we don't explicitly check to make sure you have a valid gcc > profile selected in every ebuild that calls gcc. gcc is required as part of @system. A system Java VM is not. A Java VM is a dependency just like any other that is not in @system.
As for issue 853928, AFAIK I had no Java VM installed at all. I had to install one. I'll know in 12 hours if the emerge now works.
www-client/chromium[js-type-check] depends on virtual/jre, which should pull in a Java VM. The js-type-check USE flag is enabled by default, and your build log shows it was enabled as well. I don't see how it is possible for you to have gotten into this situation unless you ran emerge --nodeps or something like that.
It won't have magically come up with icedtea. I think you probably had it installed at some point, it got depcleaned, maybe another Java got installed, but none of the Java machinery ensures that the currently set VM actually exists.
(In reply to Sam James from comment #13) > It won't have magically come up with icedtea. I think you probably had it > installed at some point, it got depcleaned, maybe another Java got > installed, but none of the Java machinery ensures that the currently set VM > actually exists. (fwiw, we've seen tonnes of examples of this, and I really do think it'd be solved by that other bug.)
(In reply to Sam James from comment #13) > It won't have magically come up with icedtea. I think you probably had it > installed at some point, it got depcleaned, maybe another Java got > installed, but none of the Java machinery ensures that the currently set VM > actually exists. You keep making the assumption that I had any currently set Java VM. That was not true in my case. I'm sorry that I don't have the problem you wish I had.
(In reply to Sam James from comment #14) > (fwiw, we've seen tonnes of examples of this, and I really do think it'd be > solved by that other bug.) All I want is a fix. If that fixes it, great.
(In reply to Gary E. Miller from comment #15) > (In reply to Sam James from comment #13) > > It won't have magically come up with icedtea. I think you probably had it > > installed at some point, it got depcleaned, maybe another Java got > > installed, but none of the Java machinery ensures that the currently set VM > > actually exists. > > You keep making the assumption that I had any currently set Java VM. That > was not true in my case. I'm sorry that I don't have the problem you wish I > had. I don't think it would've magicked up an icedtea-bin-8 unless you had it installed once. You had it installed and then it got depcleaned (probably with switch to 11 or something, or icedtea->openjdk, I dunno). I accept you did _not_ have one set at the point of the failed install. That's exactly what the other bug is about, right?
(In reply to Mike Gilbert from comment #12) > www-client/chromium[js-type-check] depends on virtual/jre, which should pull > in a Java VM. Of course. > The js-type-check USE flag is enabled by default, and your build log shows > it was enabled as well. Yeah, so, a bug. The USE flag is not being checked for its dependencies. > I don't see how it is possible for you to have gotten into this situation > unless you ran emerge --nodeps or something like that. Nope, I never, ever use --nodeps. Once a day I do: # emerge --update && layman -s ALL && emerge -uDNa world
Still pretty sure this was operator error at some point. It's extremely unlikely that Portage is just "ignoring" the dependency on its own. Bugzilla is really not a good place to discuss this; drop into IRC if you want to diagnose it further.
(In reply to Mike Gilbert from comment #19) > Still pretty sure this was operator error at some point. Since when is "emerge --depclean" an operator error? > It's extremely > unlikely that Portage is just "ignoring" the dependency on its own. I don't care how you describe it, but emerge failing on an otherwise up to date system is a bug. > Bugzilla is really not a good place to discuss this; drop into IRC if you > want to diagnose it further. I'm hanging fire until the current emerge finishes. If that works, then I'll just wait on issue 853928.
You claim to have had no Java VM installed at all. That should not be possible simply by depcleaning.
(In reply to Mike Gilbert from comment #21) > You claim to have had no Java VM installed at all. That should not be > possible simply by depcleaning. We 1,000% agree, that should not be possible. But, there it is.
I'm saying that it is much more likely that you did something weird than it happening as the result of a bug. There is not enough information to determine that conclusively.
(In reply to Mike Gilbert from comment #23) > I'm saying that it is much more likely that you did something weird than it > happening as the result of a bug. There is not enough information to > determine that conclusively. We're going in circles. Once again, I assert that I only ever do: # eix-sync # layman -s ALL # emerge -uDNa Occasionally emerge and unmerge packages. Do twice a year: # emerge --depclean This is a production server, I don't mess with it, just keep it updated. If that is weird, then I am guilty. If that is normal, then this is bug. Clearly you think I did something wrong, and clearly I think emerge should catch a missing dependency. No need to traverse the circle yet again without new facts.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6aca0f4ebb5f44ef5928536237901f780940717 commit a6aca0f4ebb5f44ef5928536237901f780940717 Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2022-06-26 08:47:02 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2022-06-26 08:47:24 +0000 www-client/chromium: add sanity check for java Closes: https://bugs.gentoo.org/853907 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> www-client/chromium/chromium-103.0.5060.53.ebuild | 3 +++ www-client/chromium/chromium-104.0.5112.12.ebuild | 3 +++ 2 files changed, 6 insertions(+)
I should apologize: in my effort to be "correct", I disregarded the obviously horrible user experience. Also, I should probably have been more careful about voicing my suspicions without evidence to back it up.
